Jak zaprojektować bazę danych. Żółtodziób

0

Witam, zaczynam przygodę z SQL i mam problem, ponieważ nie wiem jak zaprojektować najlepiej technicznie moją bazę danych.
Planuje stworzyć 3 tabele odnoszące się do strony z możliwością wyszukiwania salonów piękności z podziałem na części ciała i konkretne wykonywane usługi.

tabela 1: Salon
-idsalonu
-nazwa
-adres
-telefon...

tabela 2: części ciała:
-głowa
-włosy
-plecy
...

tabela 3: usługi:
-ujędrnianie skóry
-masaż
-usunąć owłosienie
...

Proszę o pomoc jakby musiały wyglądać pola tabel ze względu na zapis/wybór wykonywanych usług przez salon i ich relacyjne połączanie. Chciałbym oszczędzić jak najwięcej pamięci w bazie, mam rozpisanych prawie 200 usług z podziałem na 15 obszarów części ciała, każdy gabinet może w swoim profilu wybrać wykonywane zabiegi, a osoba szukająca mogłaby szukać salonów zarówno np. po rejonie a także z podziałem na konkretny zabieg lub część ciała.

Jakby wyglądało przykładowe zapytanie takiej składni? Jak zaprojektować tą bazę?

0

"Chciałbym oszczędzić jak najwięcej pamięci w bazi" - nie wiem czy to dobra rada, ale ja bym się nie przejmował na początku nauki SQL rozmiarem kolumn w bazie..

0

Rozumiem, a masz jakieś wskazówki dla mnie?Jak najkorzystniej byłoby ją zaprogramować dla programistycznych rozwiązań?

0

Ogólnie twój przykład można upchnąć w jedną tabelę. Jak chcesz to jakoś "związać" to przydałby się jakiś klucz obcy w tabeli 2 / 3, ja zrobiłbym to tak w twoim przypadku:

tabela 1: Salon

  • idsalonu
  • nazwa
  • adres
  • telefon...

tabela 2: Części ciała

  • idczęsciciała
  • nazwa (np głowa / włosy / plecy)
  • idsalonu

tabela 3: Usługi

  • idusługi
  • rodzajusługi ( np. ujędrnianie skóry / masaż / usunięcie owłosienia)
  • idczesciciala

W ten sposób możesz łatwo połączyć wszystkie tabele i jednym zapytaniem wyciągnąć informację o tym jaki salon oferuje jakie usługi. To oczywiście tylko przykład, bo rozwiązań jest wiele. Chociaż cały ten przykład jest taki sobie... Proponuję poćwiczyć sobie na coś w rodzaju schematu "Employees", gdzie masz pracowników, departamenty, stanowiska i zdecydowanie łatwiej to ogarnąć.

Pzdr.

0

@polgol zauważ, że kilka różnych salonów może się zajmować jedną częścią ciała i wtedy mamy fuckup przy Twojej propozycji.

Pewnie opiszę niegorszą herezję pod względem elegancji i da się to sensowniej wymyślić, ale zrobiłbym osobną tabelę "wiążącą" relacje pomiędzy tabelami.
Tj. ID salonu, i poszczególne zabiegi, które obsługuje lub nie w formie wartości bool.
Analogicznie dla części ciała.

Natomiast tak teraz patrzę... I nie wydaje mi się czy rozciąganie tego na kilka różnych tabel ma sens. Chyba, że części ciała i poszczególne zabiegi będą mieć jakieś dodatkowe swoje informacje, ale tu tego nie widzę i nie czuję.

Edit: A nie, jestem kretynem. Przeczytałem jeszcze raz i zbudowanie tego na tabelach pośrednich budujących relacje wydaje się mieć sens, choć jest to pewnego rodzaju dubel i mam wrażenie, że można to wykminić bardziej elegancko.

0

To jest źle, bo przed doradzaniem trzeba się zastanowić co chcesz uzyskać, i odpowiedzieć na pytanie czy salon może wykonywać więcej niż jedną usługę i czy ona może być wykonywana na więcej niż jedna część ciała.
Dwie z tych tabel jak rozumiem są słownikami, więc rozwiązanie zaproponowane przez kolegę jest bardzo złe. A jakie jest dobre to nie powiem, pomyśl, zaprojektuj i zapytaj.

2

Tutaj przydałyby się relacje wiele do wielu. Po pierwsze salon może się zajmować kilkoma częściami ciała na raz, po drugie wiele salonów może się zajmować tą samą częścią ciała, po trzecie wiele salonów może mieć podobną ofertę usług, po czwarte w końcu niektóre salony mogą mieć szerszą lub węższą ofertę usług niż inne salony. Obecnie projekt nie obsługuje żadnego z tych przypadków.

/edit: Nie mam tu na myśli, że między salonem, a częścią ciała ma być bezpośrednia relacja, myślałem o pośredniej czyli stworzyć tabele UsługiSalony i tam powiązać usługi z salonami, a w Usługach dać klucz obcy do tabeli CzęściCiała. Poza tym zastanawiam się nad sensem tabeli części ciała, czy tam będzie coś poza nazwą? Jeżeli nie, to można z niej zrezygnować.

0

w projekcie bazy brakuje bardzo ważnej tabeli łączącej salony ze świadczonymi usługami, bez której cała logika bazy sypie się,
O czym napisał już @Haskell

1

@Haskell , @autor

Poza tym zastanawiam się nad sensem tabeli części ciała, czy tam będzie coś poza nazwą?

na chłopski rozum tabela "części ciała" do niczego nie jest potrzebna, wystarczyła by tabela "Usługi". A w opisie można określić jakiej części ciała dotyczy dana usługa, unikając tym samym takich bezsensów jak połączenie usługi "depilacja" z częścią ciała "stopy" , czyli "depilacja stóp" :)

0

@grzegorz_so: na mój chłopski rozum to jest potrzebna, ale nie w takim wydaniu jak proponuje OP. Ja rozumiem, że te okreslenie cześci ciała ma służyc wyszukiwaniu salonów po np ofercie na stopy, ale częśc ciała bym powiązał z usługą nie salonem, wg mnie lepiej będzie:

Tabele "podstawowe"

tabela 1: Salon
idsalonu
nazwa
adres
telefon...

tabela 2: Części ciała
idczęsciciała
nazwa (np głowa / włosy / plecy)

tabela 3: Usługi
idusługi
rodzajusługi ( np. ujędrnianie skóry / masaż / usunięcie owłosienia)

Tabele "powiazan"
SalonUsługi
idsalonu
idusługi

UsługiCzęśćCiała
idusługi
idczescciała

0

Odpowiadam na pytanie. Tak jeden salon moze miec wiele zabiegow na wielu czesciach ciala o to właśnie mi chodzi. Osobiscie sam myslalem o koncepcji zaproponowanej wczesniej tzn. Tabela z wartosciami bool odnoszac sie do swiadzczonych usług pytanie czy to będzie praktyczne. Kazdy salon będzie mial ok 200 mozlowosci typu bool, a niektore salony z 200 beda mialy tylko powiedzmy 5 true/checked. O to wlasnie pytalem czy mozna to rozwiazac jakos inaczej,lepiej? Zapytanie i tak raczej byłoby podobne tzn. np. Select idsalony, nazwa from uslugi where uslugi = nogi.depilacja

0

@grzegotz

0

Nie będzie, dopiero po napisaniu zastanowiłem się nad tym co stworzyłem i jest to absurdalnie wręcz głupie.
Z tego prostego powodu, że jak w przyszłości dodasz nową usługę, to masz większy problem z aktualizacją bazy niż przy propozycji, którą podał Panczo.
W tym przypadku dodajesz tylko nową usługę i aktualizujesz relację zamiast robić fikoły jak koza na skałach.

Tak zresztą powinno to wyglądać, tabele łączące odnoszą się do siebie po id i mój pomysł zaiste jest zwyczajną herezją.

0

@grzegorz_so taki sam mialem zamysl. I tetaz powiedzmy szukam salonu ktory robi depilacje na nogach to skladnia zapytania wyglądałby: select * from salon where uslugi = nogi.depilacja dobrze mysle?
Jak wg Ciebie wygladalby pola w bazie? typ bool odnosnie swiadczonycj uslug czy inaczej by sie one zapisywaly nie wiem jak to w praktyce by bylo poborzecinku w jakims polu?? Jak to wyglada koledzy w praktyce moze macie jakis gotowy kod do ppbrania bym sie wprawil, pojal czy od zera mam pisac sam? Moge w c# albo asp.net mvc popracować. Dopero się tego ucze dlatego licze ma wskazówki. "Moj Nick mowi wszystko, sorry za banaly"

0

Sry mialem zamysl jak @Panczo zle spojrzalem na uzytkownika.

0

Zbyt upraszczasz te zapytania, bo to by wymagalo złączeń, czyli mniej wiecej tak:

select
   *
from
    salonuslugi as su
    inner join salon as s on s.idsalonu=su.idsalonu
    inner join uslugi as u on u.iduslugi=su.iduslugi
    inner join uslugiczesciciala as ucc on ucc.iduslugi=u.iduslugi
    inner join czesciciala as cc on cc.idczesciala=ucc.idczesciciala
where
    cc.nazwa='nogi'
    and u.nazwa = 'depliacja'

W praktyce takie zapytanie bez where zapisujesz jako widok i odpytujesz już sam widok. I raczej pytasz po kluczach nie wartościach słownikowych wtedy odpada join z czesciciala i uslugi.

Żadnych wartości bool w bazie, o tym jaki salon ma jaka usługę definiujesz w tabeli salonusługi, jak nie ma tam zdefiniowanej jakiejś to znaczy, że jej nie masz, to jest kolejny zbiór danych które musisz przechowywać. weź to na logikę jeżeli chciałbyś to przechowawać jako ciąg bitow np tak: 001100001100001110001110011101110011
gdzie każda bit oznacza konkretną usługę, to zastanów się jak rozwiążesz scenariusz:

  1. Usuwam 15 usługę -> zmieniasz bity w każdym rekordzie
  2. Dochodzi nowa usługa -> dodajesz bit w każdym rekordzie

Ile by trzeba się napracowac nad tym aby to utrzymać i panować nad tym...

0

Jeżeli w tabeli częściciała ma być tylko nazwa to jest zbędna. Wystarczy pole w tabeli usługi. Poza tym po co tabela czescicialauslugi? Naprawdę nie rozumiem...

Wystarczy coś takiego:
Salony(
Id
Nazwa
... inne pola
)

Uslugi (
Id
Nazwa
Czesc ciala
)

UslugiSalony (
IdUslugi
IdSalonu
Cena
)

/edit: ta cena pasuje do ostatniej tabeli chyba ze chcemy dodac jakas logike, np. Cenniki okreslone w czasie, rabaty dla stalych klientow, promocje itp. Wtedy potrzebne by byly kolejne tabele.

0

A ja myślę tak

Wariant 1
Tabele Salon, Usługa CzesciCiala trzy podstawowe tabele dwie słownikowe.
Dodając dwie tabele
SalonUsluga (id, id_salon,id_usluga) oraz SalonUslugaCzesciCiala (id, id_salon_usluga, id_czesci_ciala)
Dodanie tabeli SalonUslugaCzesciCiala umożliwia przypisanie do usługi części ciała bez dublowania usługi.
Czyli może być usługa strzyżenie na części ciała (głowa itp) .

Wariant 2.
Rezygnujemy z tabeli CzesciCiala, ale to skutkuje stworzeniem więcej usług.
np: strzyżenie głowy, strzyżenie coś tam itd

0

@Haskell: Czescicialauslugi jest w celu przypisania więcej niż jednej części ciała do usługi, nie jestem specem od zabiegów kosmetycznych, ale mogę sobie wyobrazić ze pewne zabiegi wykonuje się na kilku częściach, chyba ze przyjmiemy założenie że uslaga dotyczy jednej części....

0

Masz w 100% racje, ale tego nam nie powiedziano, dlatego są dwa warianty

1 użytkowników online, w tym zalogowanych: 0, gości: 1