Model do projekt zaliczeniowego SQL, ORACLE!

Ja bym powiazal producenta z produktem lub z pozycją dostawy

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ń.

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

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 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

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!

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