Krótkie pytanie! Czy ten model ma sens i będzie pięknie śmigał?
0
1
Ja bym powiazal producenta z produktem lub z pozycją dostawy
1
No to zależy czy to będzie działać od wymagań aplikacji/osoby sprawdzającej, rzeczy które można by było przemyśleć oprócz tego co kolega wyżej wskazał to:
- opcjonalność/obowiązkowość związków obecnie wszystkie wartości klucza obcego mają NOT NULL,
- zwiększenie ilości znaków w typie nvarchar dla np. ulic,
- przemyślałbym związek między składnikiem, a potrawą, może wiele do wielu,
- przemyślałbym łańcuch dostaw, receptura i jej składniki nie powinny być zależne od niej, część dostaw powinna nam odpowiadać na pytania czy mamy w magazynie wystarczającą ilość produktów,
- nie bardzo wiadomo dlaczego dwoje pracowników musi obsługiwać zamówienie.
Jednak to wszystko zależy od wymagań jakie masz odnośnie systemu. Nie można odpowiedzieć czy Twój model bazy jest dobry/zły, to zależy od konkretnych założeń.
1
Czy ten model ma sens
Jeden rabin powie tak, a inny rabin powie nie.
i będzie pięknie śmigał?
Zależy czy oddasz goły model i wyląduje w szufladzie (wtedy nie ma odpowiedzi) czy zamierzasz to wykorzystać. Jak tak to... zależy. Od ilości danych, złożoności zapytań, od tego czy pozakładasz indeksy, od miliona innych rzeczy :P
Zduplikowana kolumna i klucz obcy w tabeli ZAMOWIENIE jest celowo? Jak tak i te dwie kolumny mają jakieś konkretne znaczenie (bo nie wiem, jeden wykonuje drugi zanosi) to nazwij to jakoś z sensem, bo teraz masz PRACOWNIK_ID_PRACOWNIKA i PRACOWNIK_ID_PRACOWNIKA1
0
superdurszlak napisał(a):
Czy ten model ma sens
Jeden rabin powie tak, a inny rabin powie nie.
i będzie pięknie śmigał?
Zależy czy oddasz goły model i wyląduje w szufladzie (wtedy nie ma odpowiedzi) czy zamierzasz to wykorzystać. Jak tak to... zależy. Od ilości danych, złożoności zapytań, od tego czy pozakładasz indeksy, od miliona innych rzeczy :P
Zduplikowana kolumna i klucz obcy w tabeli
ZAMOWIENIEjest celowo? Jak tak i te dwie kolumny mają jakieś konkretne znaczenie (bo nie wiem, jeden wykonuje drugi zanosi) to nazwij to jakoś z sensem, bo teraz maszPRACOWNIK_ID_PRACOWNIKAiPRACOWNIK_ID_PRACOWNIKA1
Klucz zduplikowałem celowo, pierwszy ma odpowiadać za przyjęcie zamówienia, a drugi za jego dostawę do klienta. Opisałem to w dokumentacji projektu, ale w samym schemacie też to zmienię dla przejrzystości. Wielkie dzięki!
0
mariano901229 napisał(a):
No to zależy czy to będzie działać od wymagań aplikacji/osoby sprawdzającej, rzeczy które można by było przemyśleć oprócz tego co kolega wyżej wskazał to:
- opcjonalność/obowiązkowość związków obecnie wszystkie wartości klucza obcego mają NOT NULL,
Na pewno to przemyślę, chociaż na pierwszy rzut oka wydaje mi się, że wszystkie klucze obce są wymagane.
- zwiększenie ilości znaków w typie nvarchar dla np. ulic,
W tym przypadku muszę się zgodzić, zwiększyłem liczbę znaków dla ulic, nazw potraw oraz produktów
- przemyślałbym związek między składnikiem, a potrawą, może wiele do wielu,
Wiem co masz na myśli i poniekąd tak już jest, zauważ, że tabela składnik jest intersekcją między potrawą, a produktem
- przemyślałbym łańcuch dostaw, receptura i jej składniki nie powinny być zależne od niej, część dostaw powinna nam odpowiadać na pytania czy mamy w magazynie wystarczającą ilość produktów,
Na to na pewno poświęcę trochę więcej czasu, muszę się nad tym poważnie zastanowić
- nie bardzo wiadomo dlaczego dwoje pracowników musi obsługiwać zamówienie.
Jeden pracownik ma odpowiadać za przyjęcie zamówienie, a drugi za dostarczenie zamówienia do klienta