 czym kierować się przy rozbijaniu jednej encji na kilka w projekcie bazy? |
  |
| czym kierować się przy rozbijaniu jednej encji na kilka w projekcie bazy? |
Post
#1
|
|
 Grupa: Zarejestrowani Postów: 124 Pomógł: 0 Dołączył: 25.11.2014 Ostrzeżenie: (10%) 
 |
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? |
 |
 
|
|
Post
#2
|
|
 Grupa: Moderatorzy Postów: 36 557 Pomógł: 6315 Dołączył: 27.12.2004 |
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. -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
|
|
Post
#3
|
|
 Grupa: Zarejestrowani Postów: 340 Pomógł: 46 Dołączył: 31.07.2009 Skąd: A Ostrzeżenie: (0%) 
|
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 |
|
|
|
|
Post
#4
|
|
|
Grupa: Moderatorzy Postów: 36 557 Pomógł: 6315 Dołączył: 27.12.2004 |
@aniolekx w przypadku statusu nie ma mowy o redundancji. Chyba ze jakis geniusz zmiast tinyint czy enum uzywa varchar
 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 -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 340 Pomógł: 46 Dołączył: 31.07.2009 Skąd: A Ostrzeżenie: (0%)
|
Cytat(nospor @ 3.02.2015, 15:03:09 )  @aniolekx w przypadku statusu nie ma mowy o redundancji. Chyba ze jakis geniusz zmiast tinyint czy enum uzywa varchar 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 |
|
|
|
|
Post
#6
|
|
|
Grupa: Moderatorzy Postów: 36 557 Pomógł: 6315 Dołączył: 27.12.2004 |
Cytat 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.
-------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
|
|
Post
#7
|
|
|
Grupa: Zarejestrowani Postów: 159 Pomógł: 5 Dołączył: 31.08.2007 Ostrzeżenie: (0%)
|
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ł. -------------------- |
|
|
|
|
Post
#8
|
|
|
Grupa: Moderatorzy Postów: 36 557 Pomógł: 6315 Dołączył: 27.12.2004 |
Cytat 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
-------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
|
|
Post
#9
|
|
|
Grupa: Zarejestrowani Postów: 159 Pomógł: 5 Dołączył: 31.08.2007 Ostrzeżenie: (0%)
|
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 ;]
-------------------- |
|
|
|
|
Post
#10
|
|
|
Grupa: Moderatorzy Postów: 36 557 Pomógł: 6315 Dołączył: 27.12.2004 |
Teraz rozumiem co miales na mysli
-------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
|
|
Post
#11
|
|
|
Grupa: Zarejestrowani Postów: 2 Pomógł: 0 Dołączył: 16.02.2015 Ostrzeżenie: (0%)
|
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.
|
|
|
|
|
|
Aktualny czas: 20.08.2025 - 10:37 |
