Siemka, wrzucam poniżej schemat bazy danych którą chciałbym zaimplementować a nastepnie utworzyć aplikacje do zarządzania siłownią. Prosiłbym o ocene tego schematu i ewentualne poprawy jakby cos było źle.
W tabeli Logowanie
zamieniłbym hasło na salt i hash oraz dodał email.
Id loginu na pewno jest potrzebne?
W sumie nie jest, można by wyrzucić.
A poza tym te relacje, klucze są sensownie rozplanowane?
Przede wszystkim brakuje podstawowych informacji o procesach jakie ta baza ma obsługiwać. Stąd trudno wskazać kwestie wątpliwe. Bardzo ogólne tematy:
- Co najmniej nieczytelna kwestia kategorii zajęć, rodzaju zajęć jak i samych zajęć.
- Jak rezerwacje_zajec "przechodzą" w faktyczne zajęcia?
- Jakie produkty zamawia się np. napoje? Ilość w produkty to raczej stan magazynu. Jak zamówienia "przechodzą" w sprzedaż?
- rezerwacja_zajec - w jakim celu dzień jako varchar? Raczej mówimy o konkretnym terminie z godziną rozpoczęcia i zakończenia.
- Czlonkostwa - jak będzie widoczna sytuacja gdy klient zapisał się na roczny okres (roczny karnet) ale opłaca miesięcznie?
Dodatkowo:
-
klienci.nr_telefonu
integer. Będziesz go sumował, czy jak? -
karnety.cena
integer,produkty.cena
float - oba źle -
kategorie_zajec.rodzaj_zajec
-prosi się o słownik lub enum. Podobniepersonel.funkcja_pracownika
-
adresy
- powiat + wojewodztwo są pochodną kodu + miejscowosci. - złe nazewnictwo. O ile
Klienci.id_klienta
jest OK, topersonel.id_pracownika
już nie. - Tabela
Logowanie
jest zbędna (jej nazwa wprowadza w błąd). Te dane powinny być wPersonel
. Za to zPersonel
powinna wyl;eciećdata_urodzenia
Id_loginu powinno zostać, powinno wylecieć ID_pracownika, Brakuje wiązania do loginu z Personelu. Nie do końca wiem, jaki procesy i dane chcesz zamodelować, ale jak dla mnie to brakuje mi wiązania między rezerwacją i karnetem - aby rozliczyć rezerwacje karnetem, to chyba powinieneś mieć ten konkretny, a nie jakiś karnet klienta. Zamówienie powinno mieć nagłówek i pozycje: jak ktoś zamówi dwa różne produkty, to musisz robić dwa zamówienia.
Tak sie jeszcze czepiając: W adresie powinien być numer mieszkania, Ważność karnetu to powinny być dwie daty: od do albo data startu i ilość dni.
Wygląda, że zabierasz się nie od tej strony co trzeba, tj. od modelu danych, a nie tego jakie funkcjonalności ma ten model wspierać. W efekcie jaki ten model by nie był, to i tak rozbije się o funkcjonalności.
Marcin.Miga napisał(a):
Dodatkowo:
klienci.nr_telefonu
integer. Będziesz go sumował, czy jak?karnety.cena
integer,produkty.cena
float - oba źlekategorie_zajec.rodzaj_zajec
-prosi się o słownik lub enum. Podobniepersonel.funkcja_pracownika
adresy
- powiat + wojewodztwo są pochodną kodu + miejscowosci.- złe nazewnictwo. O ile
Klienci.id_klienta
jest OK, topersonel.id_pracownika
już nie.- Tabela
Logowanie
jest zbędna (jej nazwa wprowadza w błąd). Te dane powinny być wPersonel
. Za to zPersonel
powinna wyl;eciećdata_urodzenia
- Chodziło mi o to żeby zapobiec wpisywaniu innych wartosci niż int, ale moge zmienic na varchar a później w programie zrobić jakiegoś if'a.
- Dlaczego obydwa, myśle że jak dam float w obydwu będzie ok.
- Ale będzie wiecej mozliwosci wyszukiwania danego użytkownika.
- id_personelu masz na myśli?
- Chciałem to podzielić żeby nie robić większego zamieszania.
dbuser napisał(a): > Przede wszystkim brakuje podstawowych informacji o procesach jakie ta baza ma obsługiwać. Stąd trudno wskazać kwestie wątpliwe. Bardzo ogólne tematy: > >
-
Co najmniej nieczytelna kwestia kategorii zajęć, rodzaju zajęć jak i samych zajęć. >
-
Jak rezerwacje_zajec "przechodzą" w faktyczne zajęcia? >
-
Jakie produkty zamawia się np. napoje? Ilość w produkty to raczej stan magazynu. Jak zamówienia "przechodzą" w sprzedaż? >
-
rezerwacja_zajec - w jakim celu dzień jako varchar? Raczej mówimy o konkretnym terminie z godziną rozpoczęcia i zakończenia. >
-
Czlonkostwa - jak będzie widoczna sytuacja gdy klient zapisał się na roczny okres (roczny karnet) ale opłaca miesięcznie?
-
Co masz na myśli?
-
Tak np napoje, jakieś białko itp. Bardziej chodziło mi o to że przechodzi to troche w historie tego jakie produkty zostały zakupione i historia tego.
-
varchar dlatego że będą to zajęcia cyklicznie odbywające sie co tydzien czyli np: pon, wtorek itp..
-
może dodać coś w rodzaju statusu płatnosci.
- Co masz na myśli?
- Tak np napoje, jakieś białko itp. Bardziej chodziło mi o to że przechodzi to troche w historie tego jakie produkty zostały zakupione i historia tego.
- varchar dlatego że będą to zajęcia cyklicznie odbywające sie co tydzien czyli np: pon, wtorek itp..
- może dodać coś w rodzaju statusu płatnosci.
Ad1. tablica kategorie_zajec, a atrybuty sugerują że to jednak tablica zajęcia. Dobrze byłoby mieć słowniki dla kategorii zajęć jak i dla rodzajów zajęć jeśli są potrzebne.
Ad2. Może jednak tablica zamówienia powinna obsługiwać zamówienia różnych "produktów" tj, karnetów, konkretnych zajęć, napojów itd.w końcu za każdy się płaci bezpośrednio bądź wynika z posiadanego członkostwa.
Ad3. Czyli mogę dane zajęcia zarezerwować w dowolnym dniu tygodnia - raczej możliwy termin zajęć powinien być zgodny z grafikiem zajęć na dany okres. Wtedy wybierasz konkretną datę z czasem rozpoczęcia i zakończenia i z niej możesz odczytać dzień tygodnia.
Ad4. Pytanie, na jakie powinieneś sobie odpowiedź to - Jak można regulować płatności zarówno formy i cykle?
Jak poprzednicy już wspomnieli, napisz sobie funkcjonalności/procesy, które ma mieć Twoje rozwiązanie i dopiero w kolejnym kroku zastanawiaj się nad szczegółami technicznymi.