Witam
Muszę zrobić projekt na zaliczenie - baza danych dla sklepu komputerowego. Póki co stworzyłem model bazy i chciałbym aby ktoś go ocenił i podpowiedział co jest źle lub co można zrobić lepiej.

Na pierwszy rzut oka wygląda w porządku. Czepić się można jedynie braku flag (czy wysłano, czy zapłacono, czy aktywny itd.) + jakiegoś połączenia pracownika z zamówieniem/klientem (ale to już kwestia gustu)

Moje uwagi (oczywiście subiektywne)
1 zamówienie-usługa i zamówienie-towar: to nie jest dobre rozwiązanie gdyż wygenerowanie pozycji zamówienia będzie wymagać unii. Lepiej zrób jedną tabelę kartoteki i jedno z pól oznacz towar/usługa
2 faktury wystawia się do sprzedaży, a nie zamówień
3 cena w tabeli dostawy??
4 powinna być tabela 'zamówienia' oraz pozycja_zamówienia
5 źle rozwiązany cennik??
6 zamowienia i dostawy: to powinna być jedna tabela z flagami
7 pracownik->umowy_o_pracę+ prac_pozycję_umowy
8 pracownik->wypłaty->skladniki_wyplaty
9 Weź pod uwagę, że trzeba towar kupić, dodać marżę i na tym zarobić. Rozwiąż zakupy, marże i magazyn
10 co się stanie jak klient zmieni adres?? wszystkie faktury wcześniej wystawione również zmienią adres.....

Proponuję zacząć jeszcze raz od początku...

Myślałem nad takimi dodatkami jak status itp ale darowałem sobie. Co do pracownika i zamówienia. nie wiedziałem jak to rozwiązać więc postanowiłem ich połączyć na fakturze, ewentualnie można by połączyć pracownika z zamówieniem - nie wiem co lepsze. Jeszcze prosiłbym o weryfikacje relacji między tabelami.

bpskiba
Jeśli dobrze rozumiem to pkt 1 i 4 dotyczą tego samego czyli zamiast 2 tabel mam zrobić 1 - pozycje_zamowienia - tylko jak ona ma wygladać? Kolumny towar, usluga, cena, ilość i w wtedy w jednej linii towar albo usługa bedzie null?
Dostawa jest tabelą jak towar lub usluga czyli bedzie tam np 'Kurier XYZ' a jego cena 15zł - złe rozwiązanie?
Co do faktury - przaglądałem inne modele baz danych i stąd u mnie faktura na podstawie zamówienia, a jeśli chodzi o zmiane adresu klienta to rzeczywiscie zmieni się lecz nie mam pojęcia jak to rozwiązać.

Może warto zacząć wszystko od początku......
1 klienci (id_klienci)
2 klienci_dane(id_klienci,id_klienci_dane, nazwa,ulica,itd)
3 klienci_placowki(id_klienci, id_klienci_placowki,ulica, miasto itd)
4 transakcje(id_transakcje, id_klienci_placowki,typ, data_zlozenia,data_realizacji, status,id_faktury)
typ:zakup/sprzedaż, status: zamówione/wysłane/wycofane
5 pozycje_transakcji(id_pozycje_transakcji, id_transakcje, id_towary, ilosc, cena)
6 towary(id_towary, typ, nazwa.......)
typ:towar/usluga

to tylko szkielet do uzupełnienia i przemyślenia. magazyn, cenniki, marże pozostawię koledze :]
dodam:
- klucze obowiązkowo SERIAL
- ceny format NUMERIC

Widzisz zaletą relacyjnych baz danych są.. relacje Innymi słowy, możesz łączyć tabele z pozoru nie mające ze sobą nic wspólnego bez jakichkolwiek konsekwencji.

Jeżeli piszesz CRM to zwykle klient jest w jakiś 'magiczny' sposób połączony z pracownikiem(ami). Np podczas wpisywania klienta do bazy, pracownik, który to zrobi otrzymuje prawa opiekuna z automatu a dopiero koordynator, może je zmienić lub przydzielić innego pracownika (wszystko wedle uznania).
klient >-< klient_pracownik >-< pracownik

bpskiba
4. Błąd - łączysz placówkę ze sprzedażą, chociaż klientem częściej będzie osoba prywatna, która nie posiada owej placówki
6. Podział na usługi i towary wydaje się bardziej intuicyjny. W zamawianych produktach zapewne pojawią się specyficzne cechy jak kolor, wielkość, ilość pamięci ram a w usługach planowana ilość roboczogodzin, przydział pracownika itp. itd

SERIAL zamiast INT? toż to marnowanie zasobów
CENY - DECIMAL

bpskiba
4. Błąd - łączysz placówkę ze sprzedażą, chociaż klientem częściej będzie osoba prywatna, która nie posiada owej placówki
a jak rozwiązać sytuację, gdy adres do wysyłki jest różny od adresu na fakturę

6. Podział na usługi i towary wydaje się bardziej intuicyjny. W zamawianych produktach zapewne pojawią się specyficzne cechy jak kolor, wielkość, ilość pamięci ram a w usługach planowana ilość roboczogodzin, przydział pracownika itp. itd

Mało przekonujące argumenty. Pomiędzy cechami towarów również występują różnice np dyski mają pojemność, a nie mają prędkości drukowania (odwrotnie jak drukarki), ale nie jest to powodem aby tworzyć osobne tabele "procesory" oraz "drukarki".
Chcąc to rozwiązać należałoby stworzyć tabelę słownikową "cechy" oraz tabelę "cechy_towary"(id_cechy,id_cechy_towary,wartość)
rozbudowując bazę.... może tabela słownikowa "kategorie_towaru"

SERIAL zamiast INT? toż to marnowanie zasobów
INT: 4 byte, zakres: -2147483648 .. 2147483647
BIGINT UNSIGNED: 8 byte, zakres: 0 .. 18446744073709551615
wedle uznania... INT bez znaku może wystarczyć

CENY - DECIMAL
http://stackoverflow.com/questions/1841915...mal-and-numeric

Przejarzałem tylko pobieżnie i pierwszą rzeczą jaką mi się rzuca jest wszędzie VARCHAR(45)..... te 45 to jakaś szczęśliwa liczba dając pewność ze za zaliczenie będzie 4 albo 5?
Ot kiedy to kod pocztowy może zajmować 45 znaków? Czemu opis zajmuje 45 znaków a nie np. 255? Czemu imie zajmuje 45 znaków?

To samo z INT. Wszędzie INT, nie wierzę że ktoś moze zamówić kilka miliardów czegos. Brakuje w wielu miejscach UNSIGNED
Również mam wątpliwości co do robienia z telefonów, pinów, nipów, peselów intow

Hmm... chyba zapomniałem napisać że to nie ma być mega zaawansowana baza danych to ma być projekt na zaliczenie a mam tylko 1 semestr przedmiotu RBD, a dalsza zaawansowana przygoda z bazami danych zależna będzie od wyboru specjalizacji. Tak więc ten projekt to bardziej coś w stylu 'rozgrzewki' żeby w ogóle zrozumieć co jak działa. Za sam projekt bazy, opis, założenia, diagram ERD i model fizyczny jest 50% pkt za skrypt 35% i 15% za zrobienie zapytań do bazy przy oddaniu. Konkretnie moja baza ma mieć: 5 tablic nie licząc tablic pośredniczących, 3 związki wiele do wiele, 1 trigger, 1 stored procedure, 1 podwójny join, 5 zapytań agregujących. Tak więc dziękuję za dotychczasowe rady, ale teraz prosiłbym o bardziej łagodne spojrzenie na tą bazę

na obniżenie poziomu trudno coś powiedzieć, gdyż nie wiadomo jak nisko zejść...

Twój projekt jest jaki jest i nikt nie przewidzi, czy oceniający nie zada pytań typu:
co będzie jak klient zmieni siedzbę, czy wcześniejsze faktury zmienią adres? do tego uwagi nospora są naprawdę godne zastanowienia. Np jaki kod pocztowy ma 45 znaków lub jakie uwagi można zapisać w 45 znakach...
do tego unsigned... kto widział klucz ujemny?
triggery, procedury, zapytania... to wymaga spójnego schematu,więc może popraw model i idziemy dalej....

Jak nisko? Powiem tak... ten model który utworzyłem jest zrobiony na podstawie tego co wspólnie utworzyliśmy z prowadzącym na zajęciach - rozszerzyłem go o kilka tabel. Lecz jeśli chodzi o strukturę |towar - zamówienie i usluga - zamowienie| to takie rozwiązanie przyjęliśmy na zajęciach dlatego się tego trzymam bo na takim modelu ćwiczyliśmy zapytania. Poniżej wrzucam nieco zmieniony model bazy. Co do uwag na temat doboru typów kolumn - program w którym robiłem model automatycznie wrzucał wszędzie Varchar(45) i nawet nie zwróciłem uwagi na to przed wrzuceniem na forum Poprawiłem już chyba wszystkie błędnie dobrane typy - jeśli jednak są dalej błędy to chętnie przeczytam. Dodałem dostawce - fakturę zakupu, usunąłem informacje o zatrudnieniu itp pracownika bo to jednak zbędna rzecz jak dla mnie. No i usunąłem tabele dostawy bo wrzucę przesyłkę do tabeli usługa.

bpskiba
Powiem szczerze że ciekawa jest kwestia zmiany adresu tylko jak temu zaradzić? Bo jak zmienię adres klienta to faktura rzeczywiście pobierze aktualne dane klienta chyba że jakoś by zapisać tą fakturę w momencie jej powstania tylko jak? Niestety na zajęciach nie robiliśmy faktur w ogóle.

moim zdaniem.......krok w przód i krok w tył...
czemu klient i dostawca to różne tabele?? kontrahent, to kontrahent. A jak pojawi się sklep papierniczy, który kupi drukarkę i dostarczy papier do drukarek??
to samo tabele faktury
to samo zamówienia (możesz coś zamówić u dostawcy, lub klient może coś zamówić) Struktura danych ta sama. Wystarczy flaga
odnośnie zmiany adresu, proponowałem wyżej schemat, który to rozwiązuje (tabele klienci, klienci_dane, klienci_placowki)

data_zamowienia:TIME

A kod jest nadal VARCHAR (20)..... co ty poprawiałeś? Widziałeś kiedyś kod pocztowy 20 znakowy?

opis: char....
TEgo to już nawet nie ma co komentować.

Kolejne zmiany i kolejny model. Nie ma już klienta/dostawcy tylko kontrahent no i jednak zniknął podział towar/usługa i jest produkt Jeszcze miałbym pytanie co do typu dla pesel/nip/regon/telefon zrobiłem varchara zamiast inta - jak lepiej??
Tabelka log jest pod triggera.

Zaczyna to mieć sens
kilka uwag:
1 powiązanie faktura- zamówienie jest niejasne
2 pesel i regon to napewno są liczby stałoprzecinkowe
3 w zamówieniu niezbędny status[oczekuje, zrealizowane,zafakturowane, usunięte]
4 status należy dodać w pozycji zamówień, gdyż klient może zrezygnować z którejś pozycji
5 UNSIGNED
6 Kwestia higieny psychicznej: jeżeli tabela produkt, to kluczem głównym musi być produkt_id, i identyczna nazwa pola w tabeli zamówienie_pozycja Dotyczy to wszystkich tabel. Zamiast bezproduktywnego id obowiązkowo stosuj konwenans id_nazwaTabeli i obowiązkowo w tabelach powiązanych dokładnie nazwa klucza powiązanej tabeli i identyczny typ jak w tabeli z kluczem.
7 termin płatnoścu tinyint


Typ danych nipu i telefonu to już kwestia filozoficzna Nip ma inną maskę dla osób fizycznych, a inną dla firm, więc przechowywanie go jako INT wymaga dodatkowej flagi firma/osoba, natomiast wyszukiwanie po nip jest zdecydowanie łatwiejsze i szybsze gdy jest on przechowywany bez myślników. Podobnie z telefonami: +48, kierunkowe miast itp. Na szczęście wyszukiwanie po numerze telefonu nie jest stosowane

Zwróć uwagę, że schemat jest mniejszy, ale zapewnia te same funkcjonalności. Znacznie uprości to budowę zapytań. Uwagi higienie psychicznej pojmiesz już przy pierwszym zapytaniu.

Już po sesji, baza oddana i wpadło 4,5 Baza dosyć prosta i mało skomplikowana dzięki czemu łatwo mi było napisać kilka procedurek i triggerów bez zbędnych kombinacji. Dziękuje wszystkim za pomoc (w szczególności bpskiba)!