czym kierować się przy rozbijaniu jednej encji na kilka w projekcie bazy? Opcje

[twojastara]

Dlaczego korzystniej jest rozbić tabelę ze sporą ilością kolumn na kilka mniejszych tabel?


Mam przykładowy diagram, w którym tabela `zamowienia`połączona jest z tabelami `status` i `koszt_wysyłki`. Po co to jest rozbite na 3 tabele?

--------------------
ZAMÓWIENIE
--------------------
`Id_Zamowienia`
`Id_Klienta`
`Id_Wysylka``
`Id_Status`
`Id_Faktury`
`data`


--------------------
STATUS
--------------------
`Id_Status`
`Status`

--------------------
KOSZT_WYSYLKI
--------------------
`Id_Wysylka`
`Koszt`
`Waga`


Dlaczego nie wrzucić wszystkiego do jednej tabeli?

[nospor]

Poczytaj o tabelach słownikowych.
Czy w tym przypadku to było sensowne? A czort wie. Ja tam ze statusu nigdy nie robiłem tabeli słownikowej.

[aniolekx]

aby uniknąć redundancji,

poczytaj o relacyjnych bazach danych, pierwsze z brzegu z Googla: http://edu.pjwstk.edu.pl/wyklady/rbd/scb/wyklad5/norm.htm

Ten post edytował aniolekx 3.02.2015, 14:59:51

[nospor]

@aniolekx w przypadku statusu nie ma mowy o redundancji. Chyba ze jakis geniusz zmiast tinyint czy enum uzywa varchar (IMG:style_emoticons/default/wink.gif)

Zas zrobienie tabeli KOSZT_WYSYLKI to juz w ogole porażka. A jak dany koszt sie zmieni? Nie mozna bedzie wowczas w tej tabeli dac zmiany, bo poleci to po wszystkich starych zamowieniach. Trzeba robic nowy rekord. A nigdzie nie ma informacji, ze dany rekord jest rekordem archiwalnym

[aniolekx]

@aniolekx w przypadku statusu nie ma mowy o redundancji. Chyba ze jakis geniusz zmiast tinyint czy enum uzywa varchar (IMG:style_emoticons/default/wink.gif)

no na bank użyłby varchar...


często zdarza się scenariusz (jak zamawiam z Next'a) ze jakiegoś produktu z zamówienia akurat nie ma i musi być dosłany później, dlatego powinna być relacja jeden do wielu pomiędzy zamówieniem a wysyłka

Ten post edytował aniolekx 3.02.2015, 15:09:39

[nospor]

no na bank użyłby varchar...

Nawet jesli, to tutaj stosowanie slownika jest bez sensu... to powinien byc enum lub tinyint a nie slownik. Stany zamowienia są raczej niezmienne i nie ma sensu projektowac pod nie słownika.

[sniver]

Metoda słownikowa przy statusach zamówień jest uzasadniona, jeśli zmiana statusu zamówienia wiąże się z jakimś tam dodatkowym dzialaniem - np. wysyłany jest e-mail o zmiennej treści którą wprowadza sobie sprzedawca takiego sklepu.

Jeśli więc poza bezduszną zmianą stanu - na zasadzie - zamówienie nowe, zamówienie w trakcie, zamówienie zrealizowane <- faktycznie nie ma sensu robić słownika czy jakiejś specjalnej tabeli. Jeśli jednak ma to nieść za sobą dodatkową funkcjonalność to inaczej sie nie da, zresztą takie podejście jest o wiele łatwiej skalowalne niż gdyby statusy były polem enum w tabeli "zamówienia".

Co do kosztów wysyłki - bez sensu - ja bym to scalił.

[nospor]

Metoda słownikowa przy statusach zamówień jest uzasadniona, jeśli zmiana statusu zamówienia wiąże się z jakimś tam dodatkowym dzialaniem - np. wysyłany jest e-mail o zmiennej treści którą wprowadza sobie sprzedawca takiego sklepu.

Nie bardzo rozumiem: a co ma do tego slownik? Przy zmianie statusu mozna maila slac niezaleznie czy to jest slownik czy enum

[sniver]

Chodzi o to że sprzedawca może sobie zrobić własny model statusów i do kazdego dodać jakąś wiadomość czy jakieś tam inne rozwiązania - tak czy owak, statusy warto przerzucić jako słownik, reszte nie. To moja ocena ;]

[nospor]

Teraz rozumiem co miales na mysli (IMG:style_emoticons/default/smile.gif)

[galos]

No dobrze, ale podstawą tego wszystkiego i główną odpowiedzią na pytanie jest chyba właśnie to o czym wspomniał kolega wyżej, czyli normalizacja tabel.