Zaprojektowałem bazę danych do sklepu internetowego i mam pytanie czy taka baza będzie dobra ? Jeżeli brakuje jakiś tabel lub kolumn to liczę na wskazówki co mógłbym jeszcze tutaj poprawić bo na pewno jeszcze wiele rzeczy można poprawić.
0
1
Na pewno związek między użytkownikami a klientami wygląda dziwnie. Role powinny być w oddzielnej tabeli i powinieneś mieć jakąś tabelę pośredniczącą dla nich.
Nie masz też żadnej informacji o jakimś podziale ról. Zakładam, że skoro masz coś o rolach to chcesz oddzielić klienta od obsługi sklepu czy też administracji. Jeśli tak, to czy administrator powinien wystąpić w zamówieniu?
3
- Nie wiem czy potrzebujesz zarowno
gross_pricejak inet_price, zazwyczaj podaje sie cene netto, + dodatkowo robi sie tabele z podatkiem, ale czesciej po prostu podatki koduje sie w kodzie aplikacji. To nie jest cos co zmienia się z dnia na dzień i przy 1000 produktow to moze jest ok ale jak w slpeie masz 100k to zmiana ceny brutto jest wg mnie bardziej problematyczna(bo trzeba uruchomic migracje ktora ciezko sie testuje czy ceny sa ok) niz zmiana logiki do obliczania ceny po podatku. Dodatkowo podatek moze zalezec od kraju, regionu, typu przedmiotu, i ta logike musisz gdzies miec, albo w skrypcie do updatowania ceny albo po prostu w kodzie aplikacji... - Dodatkowo zakładasz, że jeden produkt == jeden obrazek, co raczej w zadnym sklepie nie jest prawdą.
- Brakuje chocby prostego koszyka...
- Jak realizujesz zamowienia? Bo nie widze zeby tabela
ordersmiala jakiekolwiek powiazanie z produktem poza narysowaną linią. - Według mnie relacja user <-> customer jest złą, bo z Twojego diagramu wynika, że customer może posiadać użtykownika, a domniemam, że chciałeś odwrotnie... Ze chcesz mieć administratorów, którzy nie są customerami. Teraz nie jest to naturalne, choć oszczędziłeś kilka bajtów w tabeli users(domniemam, że nie intencjonalnie).
- Dlaczego adres jest wydzielony, skoro 1 user musi mieć 1 adres? Czy adres może być współdzielony między userami(bo to jedyny powod wydzielenia, ktory widze, poza postacią normalną, której widać, nie stosujesz wdzędzie :) ) Jeśli adres może być współdzielony, to fajnie jak taki adres juz istnieje, bo nie musiusz duplikować rekordow, ale co jesli tylko jeden z uzytkownikow zechce go zmienic?
3
daniel1302 napisał(a):
- Jak realizujesz zamowienia? Bo nie widze zeby tabela
ordersmiala jakiekolwiek powiazanie z produktem poza narysowaną linią.
produkt ma id_zamowienia to dopiero jest kompletnie bez sensu
1
Tak na szybko.
Brak relacji shipment (dostawa) do śledzenia i wyboru metody dostawy.
Brak relacji payments (płatności) do śledzenia i wyboru metody płatności.
Brak wyliczonej wartości zamówienia. Czy jest potrzeba biznesowa, żeby za każdym razem pobierać produkty z zamówienia i wyliczać jego wartość na nowo?
Nieprawidłowy związek produktów z zamówieniami (patrz komentarze wyżej)
Brak ról (relacja wiele do wielu z users).
Jaki jest cel powiązania users z customers?
Pole description ma limit 45 znaków? Popatrz sobie na przykładowe opisy na allegro albo jakimś x-kom. Zwykle jest to kilkaset znaków do tego tekst sformatowany (różne wielkości liter, pogrubienia, kolory i zawierający obrazki).
Pole gross_price nie jest typem liczbowym.
Relacja opinions mogła by mieć informację o użytkowniku który wystawił opinię oraz ocenę (1-5)
1
adresses:
- Brak "poczty"
- city - 45 to za mało
- za to zip_code 10 to za dużo
- house_number i local_numer to varchar, nie int
Orders:
id_order zamiast id_orders (trzymając się twojej logiki)
opinions:
coś uboga ta tabela - chyba czegoś w niej brak
products:
skoro to katalog produktów, to nie wydaje mi się, by produkt należał tylko do jednej kategorii. Chyba, że służy to tylko i wyłącznie do umieszczenia produktu na "drzewku". No to wtedy brakuje ci dla produktów jakichś "tagó" aboco.
reszte już inni napisali.