sklep internetowy-schemat bazy danych

0

Witam, chciałbym aby użytkownicy ocenili mój schemat bazy danych i skrytykowali go. Na pewno jest jeszcze wiele poprawek. Z góry dziękuję za odpowiedź. Model logiczny w załączniku

0
  1. Sugeruję nazywać kolumny nie za pomocą samego id, tylko np. w tabeli z produktami id_produktu, w tabeli z opiniami id_opinii i tak dalej - zwiększa to czytelność kodu oraz umożliwia wykorzystanie join ... using.
  2. Dlaczego tabela dane jest osobno od tabeli klient? Tak samo tabele gwarancja, vat oraz użytkownik. Klient nie jest użytkownikiem z automatu?
  3. Czy na pewno w adresie potrzebujesz zapisywać nazwę województwa oraz powiat? To jest coś, co i tak można wyciągnąć z kodu pocztowego.
  4. Jaka jest różnica między miastem a miejscowością?
  5. W tabeli zamówienie niepotrzebnie stosujesz pełne nazewnictwo w stylu data_złożenia_zamówienia - to jest tabela z zamówieniami, wiadomo że kolumny będą się odnosić do zamówień, więc samo data_złożenia wystarczy. Jedynie robię wyjątek dla klucza głównego, tj. wtedy faktycznie id_zamówienia (ale tylko z racji kluczy obcych).
  6. Co to jest kod produktu w reklamacji?
0
Patryk27 napisał(a):

Sugeruję nazywać kolumny nie za pomocą samego id, tylko np. w tabeli z produktami id_produktu, w tabeli z opiniami id_opinii i tak dalej - zwiększa to czytelność kodu oraz umożliwia wykorzystanie join ... using.

Dlaczego tabela dane jest osobno od tabeli klient? Tak samo tabele gwarancja, vat oraz użytkownik. Klient nie jest użytkownikiem z automatu?

Osobno bo miały byc jeszcze dane do dostawcy i pracownika. Osobna tabela VAT jest potrzebna żeby przechowywać stawki vat, jeśli nagle trzeba będzie dodać vat to tylko w tej tabeli się doda. VAT będzie tj. słownikiem, który przechowuje stawki. Gwarancja będzie przechowywać "standardowe" okresy gwarancji tj. 12,24,36 miesięcy.

Patryk27 napisał(a):

Czy na pewno w adresie potrzebujesz zapisywać nazwę województwa oraz powiat? To jest coś, co i tak można wyciągnąć z kodu pocztowego.

możliwe, że nie potrzebuje

Patryk27 napisał(a):

Jaka jest różnica między miastem a miejscowością?

miasto to miasto a miejscowość no to np. wieś, wtedy potrzebna jest nazwa wsi i nazwa miasta do którego należy

Patryk27 napisał(a):

W tabeli zamówienie niepotrzebnie stosujesz pełne nazewnictwo w stylu data_złożenia_zamówienia - to jest tabela z zamówieniami, wiadomo że kolumny będą się odnosić do zamówień, więc samo data_złożenia wystarczy. Jedynie robię wyjątek dla klucza głównego, tj. wtedy faktycznie id_zamówienia (ale tylko z racji kluczy obcych).

Patryk27 napisał(a):

Co to jest kod produktu w reklamacji?

kod produktu to będzie id_produktu
jeśli chodzi o klienta i użytkownika, to opłaca się robić tabelę pracownik? osobno użytkownikiem będzie admin, klient i np. pracownik. Każdy będzie miał inne uprawnienia.
Jeszcze jakieś tabele należy dodać?

0

Osobna tabela VAT jest potrzebna żeby przechowywać stawki vat, jeśli nagle trzeba będzie dodać vat to tylko w tej tabeli się doda.
Mimo wszystko trzymałbym wartość VAT bezpośrednio w tabeli z produktami, coby nie musieć robić potem niepotrzebnych joinów i kobył.

możliwe, że nie potrzebuje
Więc usuń to z tabeli :P

miasto to miasto a miejscowość no to np. wieś, wtedy potrzebna jest nazwa wsi i nazwa miasta do którego należy
Brzmi trochę jak masturbacja "gdzie by tutaj wcisnąć więcej kolumn" - ale powiedzmy, że kupuję takie tłumaczenie (choć nigdy się z tym w branży nie spotkałem).

kod produktu to będzie id_produktu
Nie rób takich bajerów, bo się pogubisz - kod produktu to jest kod produktu, moje pierwsze skojarzenie to kod kreskowy, a id produktu to id produktu.

jeśli chodzi o klienta i użytkownika, to opłaca się robić tabelę pracownik?
Zdecydowanie zrób osobną tabelę. Klient oraz pracownik to dwie zupełnie różne role - klient może składać zamówienia, a pracownik może je moderować, lecz nie vice versa.

0

tak wiem, że dla pracownika osobna tabela

0

schemat po poprawkach, tak wgl to jest schemat sklepu internetowego (komputerowego). Miałem zapytać jak dodać np. laptop, telefon do bazy. Np. laptop potrzebuje danych typu procesor, pamięć RAM, karta graficzna, dysk twardy... a telefon przekątna ekranu. Mam pytanie jak to powinno być przedstawione w tej bazie

0

@Patryk27 przestań sobie robić jaja, stawki VAT jak najbardziej powinny być w oddzielnej tabeli.

  1. Po co koszyk w bazie?
  2. Tabela VAT jest ok, ale czemu w tabeli Produkt jest kolumna procent_vat? Tam w końcu ląduje wartość, czy id?
  3. Brakuje tabeli na pozycje faktury.
  4. Nie jesteś w stanie śledzić zmian ceny produktu w czasie.
  5. Województwa i powiaty mogą być słownikiem. Miejscowości także, chociaż nie muszą.
  6. Wsie nie należą do miast, co najwyżej do gmin, i to by miało większy sens. A jeszcze większy miałaby pozycja poczta, bo czasem kilka wsi należy do jednej i dzielą między sobą kod pocztowy. W każdym razie miasto i miejscowość w kontekście tabeli adresów to synonimy, więc jednego trzeba się pozbyć.
  7. Zupełnie nie rozumiem powiązania między tabelami pracownik a użytkownik. Jeden pracownik ma wielu użytkowników? I klient tak samo? Na moje oko tam powinno być 1:1.
  8. Po co tabela Ilość? To mogłaby być kolumna w Produkt.
0
somekind napisał(a):

Tabela VAT jest ok, ale czemu w tabeli Produkt jest kolumna procent_vat? Tam w końcu ląduje wartość, czy id?

w sumie nie wiem, przecież będzie klucz z tabeli vat

somekind napisał(a):

Brakuje tabeli na pozycje faktury.

tzn? nie rozumiem

somekind napisał(a):

Zupełnie nie rozumiem powiązania między tabelami pracownik a użytkownik. Jeden pracownik ma wielu użytkowników? I klient tak samo? Na moje oko tam powinno być 1:1.

miało być coś w stylu, że wielu użytkowników to klienci, ale to nie ma sensu

somekind napisał(a):

Po co tabela Ilość? To mogłaby być kolumna w Produkt.

ilość miała przechowywać ile sklep posiada danego produktu, ale to chyba nie ma sensu

0
student123 napisał(a):

w sumie nie wiem, przecież będzie klucz z tabeli vat

W takim razie kolumna powinna nazywać się raczej id_stawki_vat. Pamiętaj, że stawka VAT nie zawsze jest liczbą, bo oprócz stawek: 23, 8, 5 i 0% jest jeszcze sprzedaż zwolniona z VAT i nie podlegająca VAT.

somekind napisał(a):

Brakuje tabeli na pozycje faktury.

tzn? nie rozumiem
Wiesz jak wygląda faktura?
W skrócie - zawiera dane kupującego, sprzedającego, oraz listę produktów/bądź usług, które są sprzedawane. Każda z nich ma nazwę, ilość, jednostkę miary, cenę jednostkową netto, stawkę VAT, cenę brutto i wartość brutto (czyli ilość * cena brutto). Ta lista produktów/usług, to właśnie pozycje faktury. Na Twoim diagramie czegoś takiego nie widzę.

somekind napisał(a):

ilość miała przechowywać ile sklep posiada danego produktu, ale to chyba nie ma sensu

Sens ma, tylko raczej nie jako oddzielna tabela.

0

jest faktura po prawej stronie schematu.

0

Dlaczego zakładasz, że zawsze faktura będzie się 100% pokrywać z produktami w zamówieniu?

0

bo jeszcze nie trafiłem na sklep w którym mogłem sobie wybrać co chce mieć na fakturze. zawsze było to co w zamówieniu, na paragonie

0

Co gdy cena produktu się zmieni od czasu wystawienia faktury?
Dane w Twoim systemie wtedy będą rozbieżne z fakturą papierową.

Poza tym niektóre firmy wystawiają np. faktury w innej walucie.

0

proponujesz podwójnie przechowywać np cenę?

1

Cenę, nazwę, próg podatkowy - wszystko.

0
student123 napisał(a):

jest faktura po prawej stronie schematu.

Tak, jest Faktura, ale nie ma PozycjiFaktury. Nie wiem jak to prościej wytłumaczyć...
Spróbuję w ten sposób - gdzie trzymasz informacje o tym, ile sztuk danego produktu kupił klient?

1

Dodam od siebie - IMO jeszcze sporo do poprawy w tym modelu:

  • nie za bardzo rozumiem wydzielenie z klienta osobnej encji na adres - zakładasz, że pod jednym adresem będzie wielu klientów ?
  • encja dane - to samo co z adresem - wszystko powinno być w encji klient
  • encje użytkownik i pracownik - co chciałeś nimi wymodelować ? - nazwę użytkownika, login i hasło również można wrzucić do klienta
  • ilość produktu - raczej jako atrybut obowiązkowy - to są kluczowe dane ile czego mamy na stanie

Wspomniane Pozycje_Faktury - jak napisali przedmówcy - muszą być modelowane osobno ponieważ nie da się tego zrobić jako atrybut encji Faktura - a jakoś trzeba przechowywać informację o tym czego, ile i za ile było na fakturze.Tabela
POZYCJE_FAKTURY powinna być imo tutaj "pomiędzy" produktem i fakturą i wchodzić z nimi w związek (jeden po stronie faktury - wiele po stronie pozycje_faktury).

Spróbuj opisać sobie związki między tabelami po każdej ze stron co mniej więcej robią - np. Faktura (zawiera) Pozycje_Faktury, Pozycje_faktury (wchodzą w skład) Faktura - to wbrew pozorom nie jest proste, ale potrafi sporo rozjaśnić

0
Pablitto77 napisał(a):
  • nie za bardzo rozumiem wydzielenie z klienta osobnej encji na adres - zakładasz, że pod jednym adresem będzie wielu klientów ?
    dokładnie tak
Pablitto77 napisał(a):
  • encja dane - to samo co z adresem - wszystko powinno być w encji klient
    to w pracowniku znowu mam mieć dane na jego temat? jakbym chciał przechowywać dane moich pracowników w bazie to jak skoro mam mieć adres w kliencie? wtedy muszę mieć też adres w pracowniku
Pablitto77 napisał(a):
  • encje użytkownik i pracownik - co chciałeś nimi wymodelować ? - nazwę użytkownika, login i hasło również można wrzucić do klienta
    bo miały być 3 typy użytkowników: klient, pracownik i admin. Każdy miał mieć inne uprawnienia i dlatego są rozróżnieni na pracownik i klient, bo u nich potrzebuje innych danych na ich temat. Czyli np. kiedy pracownik został zatrudniony, a w kliencie tego nie potrzebuje. Pracownik i klient mają wspólne to że potrzebują się zalogować, czyli do tego jest encja użytkownik

1 użytkowników online, w tym zalogowanych: 0, gości: 1