Widzę, że znowu dodałeś te kolumny dostępność w tabelach Produkt i Stolik (swoją drogą nazwa Stolik tutaj nie do końca pasuje, lepiej nazwać tą tabelę Rezerwacja, bo właśnie tego typu dane przechowuje ta tabela). Ja je usunąłem celowo w tym diagramie co wrzuciłem. Możesz mi powiedzieć po co Ci są te kolumny?
W przypadku tabeli Produkt zauważ, że nawet jeśli będziesz miał informację o tym, że dany produkt jest dostępny to i tak ta informacja guzik daje (tzn. może nie guzik, ale jest niewystarczająca). I tak musisz sięgać do tabeli Magazyn, żeby wiedzieć jaka ilość tego produktu jest dostępna, żeby wiedzieć na jaką ilość produktu możesz przyjąć zamówienie (rozumiem, że docelowo będzie możliwość składania zamówień przez internet?).
Jeśli chodzi o kolumnę dostępność w tabeli Stolik, to lepiej jest użyć zamiast tego czegoś w stylu statusu. Czyli klient ma możliwość zarezerwować stolik, anulować rezerwację lub potwierdzić rezerwację. Jeśli stolik ma status zarezerwowany na dany dzień i godzinę no to znaczy, że jest niedostępny. Jeśli klient anuluje rezerwację to automatycznie stolik staje się dostępny na dany dzień i godzinę.
I jeszcze jedno. Zauważyłem, że w tabeli Użytkownik wprowadziłeś ten enum zamiast osobnej tabeli UzytkownikTyp. Jeśli już decydujesz się na takie podejście to IMO powinieneś też usunąć tabele ZamowienieTyp, StatusZamowienia (nazwa ZamowienieStatus jest lepsza) oraz JednMiary i zamiast nich też użyć tego enuma. Chodzi mi o to, żeby trzymać się jakiegoś schematu.
Z tabeli Produkt zapomniałem usunąć kolumny dostępnosc. Tabela Stolik pokazuje stoliki wolne, zajęte, tudzież zarejestrowane (kolumna dostepnosc). Jednak zauważam różnice w nazewnictwie, przejdę do nazwy status i wspomnianego wcześniej słownika.
Tak, ma być możliwość składania zamówień przez Internet. Zauważyłem zbędną kolumnę dostepnosc w tabeli Produkt.
Obecnie częściej stosuje się typ wyliczeniowy enum czy tak jak powiedziałeś słowniki? Czy jest to zależne od osoby projektującej bazę?
Tabela Stolik wydaje się mi być czytelniejsza od Rezerwacja z tego względu że będziemy mieć np. stolik_id od 1 do 12 (przypadek gdy w restauracji mamy 12 stolików). I tabela ta będzie update’owana w momencie rezerwacji stolika, czy też jej anulowania.
Upraszczasz, nie ma tak, że w aplikacji używamy tego albo tego w zależności od własnych chęci. Trzeba dobrać odpowiednie rozwiązanie do potrzeb.
Jeśli jakaś opcja ma być udostępniona użytkownikowi do edycji, np. w formie listy wyboru, to najlepiej zrobić tabelę słownikową, tak aby mieć wartość klucza i nazwę (do wyświetlenia). Wówczas podpina wypełnia się danymi z niej jakiś dropdown i użytkownik może swobodnie na tym działać.
Natomiast jeśli takie coś jest automatycznie ustawiane przez aplikację podczas wykonywania jakichś tam operacji, to wystarczy enum - bo użytkownik nie musi widzieć “nazw” tych opcji.
Ma to sens, ale pod warunkiem, że rezerwację można wykonywać tylko z jednodniowym wyprzedzeniem. Co w sytuacji, gdybyś chciał np. umożliwić klientom rezerwować dany stolik na różne dni tygodnia/godziny ?
Pewno masz rację. Ja nigdy z enum-ami używanymi jako typ kolumny nie miałem styczności.
Rozumiem. A to w takiej sytuacji nakładasz sobie jakiś constraint na kolumnę, czy jak? W sytuacji używania słownika ma się ten problem z góry załatwiony.
W sprawie słownika problem załatwiony, tylko zapytania wolniejsze. No i nie zawsze jest to potrzebne.
Nie nakładam żadnego constraintu, aplikacja i tak zawsze zapisuje tam wartości z enuma, więc mowy o błędzie nie ma. A jak ktoś ręcznie wpisze tam jakieś śmieci, to najwyżej za karę mu się tę rękę utnie.
