Projekt bazy danych dla sieci sklepow

Witam,
nie do konca umiem sobie poradzic z projektem takiej bazy danych. mianowicie problem sprawia mi zaprojektowanie tabel dotyczacych produktow w taki sposob aby dane sie nie powtarzaly. Chcialbym zeby w bazie mogly byc przechowywane dane dotyczace np. nart, butow a takze lokalizacji w jakich mozna je znalezc. Problem sprawia mi to ze narty, buty spodnie maja rozne parametry. tzn. np.
narty - dlugosc, przeznaczenie
buty rozmiar stopy
spodnie rozmiar w sensie S,M,L
Obecnie czesc bazy danych dotyczaca produktow wyglada tak:

PRODUKT
ID_Produktu PK
Producent
Nazwa
Opis

NARTY
ID_Prod PK
ID_Produktu FK
Dlugosc

LOKALIZACJA_PROD
ID_Lokalizacji FK
ID_Prod FK
Sztuk

LOKALIZACJA
ID_Lokalizacji PK
Nazwa
Miejscowosc

W takim stanie mozna bezproblemowo obsluzyc narty ale nie umiem sobie poradzic z innymi produktami. Czy dla kazdego tworzyc osobne tabele? Czy tabele narty zamienic na ogolna i wrzucic tam wszystkie parametry (dlugosc, rozmiar, rozmiar stopy) i niektore zostawiac null w przypadku gdy nie charakteryzuja produktu.
Pozdrawiam serdecznie i licze na pomoc.

imo najlepiej będzie dla każdego rodzaju produktu potworzyć osobne tabelę - analogiczne do tej jaką stworzyłeś dla nart.

pozdrawiam
Antek

Moim zdaniem chyba zwariowaliście. A jak produktow będzie np. 1000 to będziecie mieli 3000 tabel?
To życzę powodzenia ;]

Shalom napisał(a)

Moim zdaniem chyba zwariowaliście. A jak produktow będzie np. 1000 to będziecie mieli 3000 tabel?

Tokiem myslenia kolegi to ewentualnie moze dla 1000 produktow - 1000 tabel
ale i o to nie chodzilo, tylko o zalozenie osobnej tabeli na kazda kategorie produktow
tak poki co roboczo u mnie wyglada, ze dla kazdej kategorii jest osobna tabela
a w jeszcze innej tabeli tabeli przetrzymywane sa informacje dotyczacych parametrow wspolnych dla kazdego z produktow czyli model, producent
Tylko nie wiem czy to jest jedyne i sluszne rozwiazanie?
pozdrawiam

Pytanie brzmi czy te dane, które dla każdego typu produktów są różne, są ci potrzebne z osobna.
Bo jeśli nie są to możesz zrobić pole Opis produktu gdzie te dane zamieścisz.
Nawet wyszukiwanie można wtedy od biedy zrobić za pomocą Like i odpowiedniego regexpa.

Innym rozwiązaniem może być stworzenie dodatkowej tabeli dla każdej kategorii produktu, ale to spora komplikacja, bo dodatnie nowej kategorii produktów będzie wymagało zmian w schemacie bazy danych i w procedurach, co nie powinno mieć miejsca.

Nawet nie szalej z takimi tabelami na każdy typ produktu, nie tylko o bazę tu chodzi, ale w samej aplikacji byłaby eksplozja klas/procedur, powtórzeń i samych złych rzeczy.

Tak jak @Shalom napisał, tylko pole opis. Pomyśl o jakimś odpowiednim formatowaniu opisów, żeby łatwo można go dostosować do wyświetlania html.

rozumiem, za patrzycie na to pod katem tego zeby aplikacja to latwo obsluzylo i w ogole bylo wygodnie, ale glownym celem jest zaprojektowanie relacyjnej bazy danych, dlatego probuje to jakos pogodzic
poki co nie jest tak duzo tych kategorii bo np. narty i snowboardy opisuje tymi samymi parametrami czyli dlugosc i przeznaczenie (oprocz podstawowych czyli prodcent itp ktore siedza w tabeli produkt)
i na razie mam 3 takie tabele z dodatkowymi parametrami, ale dzieki za kazdy pomysl na rozwiazanie tego problemu

Ok, ale celem jest chyba zaprojektowanie DOBREJ bazy. Żebyś sie nauczył jak nalezy to robić. A to co chcesz zrobić temu przeczy. Nie wiem jak sobie wyobrażasz korzystanie z takiej bazy, czy też napisanie do niej procedur. O aktualizacjach pisałem powyzej. Myślisz ze ktos by kupił taki system, w którym dodanie nowego produktu pociąga za sobą zmiany w kodzie systemu i w schemacie bazy?
Jeśli to jest projekt na uczelnię to idź do prowadzącego o tym pogadać, ale on raczej powie ci to samo co my.

Dobre zaprojektowanie bazy to takie po ktorym nie bedzie trzeba tworzyc dodatkowych tabel azeby dodac produtk, zgadzam sie, ale to sie wcale nie gryzie z obecnym relacyjnym projektem
nie mieszajmy tutaj modelowania logicznego z implementacja w konkretnym dbms i napisania interfejsu
selecty moze i beda dlugie ale przeciez beda napisane raz, a mozliwosc wyszukania narty po dlugosci wydaje mi sie podstawowa funkcjonalnoscia takiego projektu wiec musi to byc jakos sensownie zaprojektowane a nie dookola

Podepnę się do tematu również z zagadnieniem produktów.

Mam tabelę klientów, zamówień i produktów. W zamówieniach jest FK na id w klient a co zrobić ze wskazaniem na produkt? W jednym zamówieniu można zamówić wiele produktów, więc jak zrobić żeby pojedynczy rekord opisujący dane zamówienie mógł zawierać kilka produktów? Rozwiązanie to oczywiście wiele rekordów do jednego zamówienia, każdy do innego produktu ale to chyba nie jest dobre rozwiązanie...
Sytuacja jest chyba dość standardowa, zamówienia i produkty więc jest chyba jakiś "utarty" schemat?

(Jeśli moderator uzna że powinien to być osobny temat proszę o przeniesienie)

bedziesz mial powiazanie N:M pomiedzy tabelami zamowienia i produkty
dodajesz jeszcze jedna tabele
wrzucasz do niej id_zamowienia i id_produktu. oba jako FK, a ich para tworzy PK

Zapewniam cię że umiejętne wykorzystanie regexpów i skorzystanie z tabeli z kategorią produktów powinno załatwić sprawę szukania. Rób jak chcesz, ale twój pomysl jest po prostu zły, niezależnie od tego jak sobie to chcesz usprawiedliwiać.
Jeżeli ilość możliwych kategorii produktu jest ściśle określona i mała, tzn wiesz że będą to np. tylko i wyłącznie narty, deski i buty to można od biedy tak zrobić jak chcesz. Ale jeśli to ma być po prostu "baza sklepu ze sprzętem" to moim zdaniem absolutnie odpada.

@Lancer tak jak napisał @banglalo, tworzysz sobie tabelę SzczegolyZamowienia gdzie masz pary IdProduktu, IdZamowienia (i fajnie tutaj też wrzucić np. ilość produktów tego typu które ktoś kupił)

nie wiem czemu traktujesz pomysl jako zly, mam wrazenie ze go niedostatecznie przeanalizowalas, a nawet jestem w stanie sie pokusic o stwierdzenie ze zapoznales sie tylko z pierwszym pomyslem.
jak juz mowilem celem jest zaprojektowanie relacyjnej bazy danych wiec wrzucenie kilku parametrow w jedno pole jest nie do przyjecia i tu kropka. w sklepie ze sprzetem zawsze ilosc kategorii bedzie ograniczona, nie zaczna nagle sprzedawac ryb.
tymbardziej ze te kategorie potraktowalem dosc luzno takze poki co sa 3 i poki co wszystkie moje pomysly sprzetu zimowego mieszcza sie w nich.
zostaly zaimplementowane w modelu na podstawie hierarchii encji wiec pasuje do modelu relacyjnego
dziekuje za Twoje sugestie, ale naprawde zalezy mi na tym aby model ten mozna bylo nazwac relacyjnym.
Jakby to mial byc projekt do sklepu "na sprzedaz" to walnalbym to w jedna tabele i w niepotrzebnych parametrach wpisal nulle badz jakas wartosc neutralna i ze wzgledu na to ze tych produktow nie bedzie 100tys baza bedzie hulac, ale jak juz wspominalem nie o to chodzi :)

@banglalo - doceń doświadczenie innych, źle myślisz, Twój problem nie jest wcale jakiś szczególny żeby tak nad nim rozkminiać. Moim skromnym zdaniem źle pojmujesz relacyjność db.

Napisałeś szukanie narty po długości, no dobra, ale nie tylko narta ma długość, nie sądzisz?
Z tego co pamiętam z zajęć db, redundancje, jak to ładnie wykładowca mówił;) w bazie nie są mile widziane...a taki sposób myślenie właśnie do tego może doprowadzić?

Wg mnie za określenia tego co szukać system odpowiada również kategoria. Kategorie można powiązać rodzic-potomek w jednej tabeli. Relacje mogę być przecież w stylu id->parent_id.
Zresztą to jest standard postępowania...

Przykład - Sprzęt Zimowy > Narty > Szukaj('długość 190').

Najpierw idzie po kategoriach, użytkownik wybiera sprzęt zimowy, otrzymuje kolejne opcje do wybrania, w tym też narty, a później tak jak pisał @Shalom masz regeksy i inne rzeczy, którymi możesz wyciągnąć tę długość, także nic nie stoi na przeszkodzie, by było to właśnie w polu zawierającym szczegółowy opis produktu. W nie każdym produkcie ważna jest długość, więc chyba jasne, żeby to w opisie zapisać.

I teraz po co do tego osobne pole długość i w ogóle osobna tabela dla nart?

Troszke sie koledzy uparliscie:)
w pierwszym poscie pokazalem problem i ze to rozwiazanie bylo zle, slabe nierelacyjne to wiedzialem
w ktoryms z pozniejszych postow opisalem nowy pomysl, nie wiem czemu sie do niego nie odwolujecie. Sporbuje po krotce opisac raz jeszcze
a wiec np dla nart snowboardow i rzeczy ktore mozna opisac takimi samymi parametrami jedna tabela z tymi szczegolowymi parametrami np CechySprzetuZjazdowego i ta tabela bylaby wlasnie powiazana po id_produktu jako child
a w tabeli Produkt siedzialaby reszta parametrow wspolna dla wszystkich sprzetow
A relacyjnosci nie zaczynaj bo skoro chcesz/chcecie wrzucic kilka parametrow w jedno pole to taka baza nie bedzie nawet w pierwszej postaic normalnej bo owe pole ni chu chu nie bedzie mialo wartosci atomowej
i po raz kolejny zaznaczam ze gdyby to byl projekt komercyjny na pewno szybciej latwiej i czytelniej byloby zrezygnowac z modelu relacyjnego, pojsc na pewne kompromisy i gdybym o to pytal to swietnie, ale ja chce ten problem rozwiazac w modelu jak najbardziej relacyjnym i o to pytam od poczatku. Wydaje mi sie ze obecne rozwiazanie bedzie najlepsze ale moze ktos mial podobny problem lub ma lepszy pomysl, ale prosze bez wrzucania wszystkiego w jedno pole:)
Pozdrawiam

O czym Ty piszesz?

Atomowość? każdy opis jest inny...

Opis to pojedynczy typ...
Jakby atomowość brać tak dosłownie to imię Kinga, też można by podzielić na K-i-n-g-a

Pole w tabeli to nie tylko pojedyncza wartość/liczba/zdanie

Jakby tak było to po

chu chu
pola to przechowywanie dużej ilości danych typu TEXT czy BLOB?

No chyba że fragment tekstu dzielić na akapity, akapity na zdania, zdania na słowa, słowa na samogłoski/spółgłoski i może od razu podróż do wnętrza ziemi.

GhostDog napisał(a)

O czym Ty piszesz?

Atomowość? każdy opis jest inny...
Pole w tabeli to nie tylko pojedyncza wartość/liczba/zdanie

no wlasnie w relacyjnych tak.
mozesz przechowywac zdanie, opis ok jak najbardziej
ale w tym opisie jak wrzucasz ogolny opis plus producenta narty, dlugosc, jej przeznaczenie to juz sa 3 rozne wartosci
adresu tez nie trzymasz w 1 kolumnie prawda?
masz ul, kod miasto
ta sama zasada
taka jest teoria relacyjna i jej chcialbym sie trzymac
jezeli nie slyszales o atomowosci pola to nie bardzo mamy o czym rozmawiac
http://pl.wikipedia.org/wiki/Posta%C4%87_normalna_%28bazy_danych%29#Pierwsza_posta.C4.87_normalna_.281NF.29
to sa naprawde podstawy

To są pierdoły świata akademYckiego... a on jakby w dużej części zatrzymał się gdzieś w miejscu dawno temu, rzeczywistość jednak ciągle ewoluuje, a i wymagania się zmieniają.

Producent narty?

Nie znam się na nartach ale pewnie jeden producent nie produkuje tylko nart, ale także obuwie, wiązania, może ubiór itd. Producenci - być może zasługuje na osobną tabelę, to nie jest opis szczegółów produktu, a to chyba o to się rozchodzi...

Twój sposób pojmowanie, moim zdaniem spowodowałby między innymi powtórzenia pola długość w tabelach dotyczących różnych produktów, dla których długość jest istotną cechą. Już lepiej uznać, że w kążdym produkcie do sportów zimowych ważna jest długość i w głównej tabeli mięć pole długość , a jak nie trzymać nulla...

To moje sugestię, zrobisz przecież jak zechcesz, ale o relacyjności nikogo też tu nie pouczaj...
Jeśli chcesz to przyjąć w sposób twardo-głowych no to zostaw to tak jak masz, pewnie i wykładowca będzie zadowolony

Nie mialem zamiaru przyuczac. To ty sie oburzyles kiedy napisalem o atomowosci pola, ale nie to jest istotne.
niestety swiat akademicki wciaz mnie dotyczy dlatego tez zalozylem ten temat.
Teraz postaram sie opisac moj obecny pomysl.
Ponizej wycinek z modelu w wersji uproszczonej:

Produkt (ID_Produktu PK, Producent, Model)
Cechy_narty_deski (ID_Produktu PFK, Długość, Przeznaczenie)
Cechy_buty (ID_Produktu PFK, Nr_Buta, Kolor)

Producenta i model nalezy przeniesc do osobnej tabeli w celu unikniecia powtorzen
Cechy_narty_deski moga uszczegolowic opis narty, deski nawet kijka
Cechy_buty butow narciarskich snowboardowych zimowych

I w tabeli produkt moga powstac np takie wpisy:
1 Burton Custom
2 Burton Custom
3 Burton Custom

i odpowiadajace im wpisy w cechach nart desek:
1 152 Freestyle
2 158 Freestyle
3 162 Freestyle

tak mniej wyglada moj pomysl i szukam ewentualnie lepszego ale nie uciekajacego skrajnie od modelu relacyjnego
w tym projekcie chodzi bardziej o teoretyczne podejscie do problemu stworzenie bazy jak najbardziej relacyjnej
@GhostDog moze Cie to frustrowac ale takiego czegos potrzebuje a nie bazy polegajacej na kodzie aplikacji

Wcale się nie oburzyłem, ani mnie to nie frustruje, tak jak napisałem zrobisz jak zechcesz.

Tylko but też ma pewnie przeznaczenie, do jakiegoś typu nart, nr buta to jakby odpowiednik długości narty, kolor buta i narty widać na zdjęciu, ale wspomnieć można, przecież osoba niedowidząca może chcieć kupić komuś narty, być może dla niej będzie w opisie ważny kolor i buta i narty, więc sam widzisz...

Ale po "akademicku" jest ok, nie mogę coś spać, stąd może takie rozkminy. Luzik.

no tak mozna sie spierac gdzie jaki parametr wrzucic, ale nie o to chodzi
nalezy przyjac ze kolor odnosi sie tylko do butow:)
but moze charakteryzowac sie stopniem twardosci, ale tu nie chodzi o mega praktyczne zastosowanie tylko pokazanie ze da sie.
jestem ciekaw tez jak rozwiazane to jest w wiekszych firmach, które sprzedaja towar, produkty roznego rodzaju, ale znajac zycie nikt sie nie bawi w poprawne modele tylko dla kazdego produktu osobna tabela i tyle, albo wszystko w jedna ale to imo najgorsze rozwiazanie.

Gdyby było tak jak mówisz i ludzie robili takie bazy to większe sklepy czy firmy by po prostu padły.
Wydaje mi się że nie po to pensje bazodanowców zaczynają się od 5 cyfr żeby takie rzeczy robili.

A atomowość chyba troche źle potrzegasz. Atomowość ze względu na zastosowanie danych!

adresu tez nie trzymasz w 1 kolumnie prawda?
masz ul, kod miasto

Guzik prawda. Jeśli nigdzie nie korzystasz z samego miasta, albo z samej ulicy to możesz to wstawić do jednego pola tabeli.

Shalom napisał(a)

Gdyby było tak jak mówisz i ludzie robili takie bazy to większe sklepy czy firmy by po prostu padły.

nie mam takiej wiedzy...ale skoro tak twierdzisz

Shalom napisał(a)

A atomowość chyba troche źle potrzegasz. Atomowość ze względu na zastosowanie danych!

kluczowe w tej czesci bedzie slowo chyba jak dla mnie:)

Shalom napisał(a)

Guzik prawda. Jeśli nigdzie nie korzystasz z samego miasta, albo z samej ulicy to możesz to wstawić do jednego pola tabeli.

Mozesz wszystko, tylko potem nie mozesz nazwac takiej bazy danych w pelni relacyjna, a poza tym ja chce wyszukac np snowboardy freestylowe o dlugosciach 155-162cm dlatego staram sie przechowywac wartosc dlugosc i przeznaczenie w osobnych kolumnach</quote>

Produkty powinny być w jednej tabeli. Parametry wspólne dla większości produktów powinny być w tabeli Produkty. Parametry produktów, które są specyficzne dla danego typu produktu powinny się znaleźć w tabeli Parametry i powiązane z produktami w tabeli ProduktyParametry wraz z wartością parametru, ew. mogą zostać w tabeli Produkty i nie być wypełnianie dla produktów, których nie można opisać w dany sposób.

Tworzenie osobnych tabel dla każdej kategorii produktów to bardzo zły pomysł.

@AdamPL dzieki za wypowiedz, w koncu cos zwiazanego z tematem
rozwazalem rowniez zaprezentowany przez Ciebie sposob, tylko zastanawialem sie jaki typ danych nadac kolumnie wartosc w tabeli ProduktyParametry? bo beda tam i liczby i oznaczenia rozmiarów(S,M,L), a takze slowa. Czy jezeli ustawi sie go na varchar to czy bedzie istniala mozliwosc wyszukiwania np sprzetu o dlugosci od do poslugujac sie tylko SQLem?

A wracajac do mojego pomyslu z kategoriami - czy w przypadku zamknietej ilosci tych grup kategorii to jest rowniez zly pomysl i dlaczego?
obecnie chcialem stworzyc 3 grupy
dla nart i snowboardow
dla butow wszelkiego rodzaju
dla odziezy akcesoriow ( wszystko co bedzie mozna opisac rozmiarami S,M,L, XL)
mozna to uznac za grupy obejmujace 99% produktow sprzedawanych w takich sklepach

Chociaz bardziej sklaniam sie rozwiazaniu przedstawionym przez AdamPL to chcialbym wiedziec co nieprawidlowego jest w tym pomysle.

EDIT
Do pomyslu AdamPL dodalbym jeszcze jedna tabele WYST_PROD tak zeby zlikwidowac powtorzenia w przypadku wystapienia tego samego modelu np narty ale o roznej dlugosci
ulatwia to tez powiazanie konkretnego produktu z jego lokalizacja
oto czesc schematu

PRODUKT
ID_Produktu PK
Producent
Model
Cena

WYST_PROD
ID_Wyst_Prod PK
ID_Produktu FK

PARAMETRYPRODUKT
ID_Wyst_Prod FK
ID_Parametru FK
Wartosc_parametru

LOKALIZACJA_PROD
ID_Lokalizacji FK
ID_Wyst_Prod FK
Sztuk

Dzieki temu jezeli podany model narty wystapi w 3 roznych dlugosciach: producent model oraz cena pojawia sie tylko raz w tabeli produkt, a w tabeli wyst prod pojawia sie 3 pary ID
Jak oceniacie ta modyfikacje?

1. Tak gdy ustawisz typ varchar to bez problemu będziesz mógł wyszukać. Jest tylko jedna rzecz na którą musisz zwrócić uwagę... Gdy będziesz wyszukiwał przykładowo długość nart na całej takiej tabeli bez podania nazwy parametru to takie zapytanie się wywali.

Ten kod będzie próbował castować pole wartość na numeric, jeżeli w polu wartość znajdzie varchar np. rozmiar 'S', 'M', 'XXL' to się wywali:

SELECT produkt
FROM ParProd
WHERE wartosc > 12.3

Żeby taki kod działał należy w warunku WHERE podać nazwę parametru co do którego mamy pewność, że jest tam numeric:

SELECT produkt
FROM ParProd
WHERE parametr = 'dlugosc' AND wartosc > 12.3

Żeby mieć pewność, że w dla danego parametru jest wpisany ten sam typ danych wystarczy przechowywać typ danych w tabeli parametry (ta ogólna) i przed wstawieniem rekordu do tabeli ParProd sprawdzać czy podano wartość odpowiedniego typu.

2. Powodem dla którego nie powinieneś tworzyć osobnej tabeli dla każdej kategorii jest fakt, że w przypadku jakiejkolwiek zmiany w tabelach z produktami będziesz musiał ją wykonać na każdej tabeli z produktami z osobna. Gdy będziesz chciał wyszukać różne produkty wg wspólnej cechy np. wszystkie narty, buty, wiązania jednego producenta albo wszystkie produkty w określonym kolorze to będziesz musiał wyciągać dane z kilku różnych tabel i je w jakiś sposób łączyć. Uważam, że z tego powodu uciążliwości jest to złe rozwiązanie.

Generalnie pomysł zapodany przez Adama jest chyba najlepszy (wspólne parametry w tabeli Produkty, unikalne w tabeli Parametry) tylko, że jest cholernie niewygodny w późniejszym użyciu. Dodatkowo przy takiej metodzie nie zastosujesz indeksów w zapytaniach zawierających parametry.

Jeżeli używasz MSSQL2008 to jest nowy mechanizm rozwiązujący dokładnie ten problem - kolumny Sparse. Wartość w takiej kolumnie, jeżeli istnieje, to zajmuje więcej miejsca na dysku, ale jeśli nie (NULL) to nie zajmuje w ogóle. Używając tego mechanizmu wrzucasz wszystkie parametry do jednej tabeli - masz prostsze zapytania, możesz zakładać indeksy, etc. Oczywiście kłóci się to trochę z klasycznymi regułami normalizacji, ale jak już zostało wcześniej powiedziane, reguły gry cały czas się zmieniają (jeżeli byłyby sztywne, to nie wrzucaliby tego typu kolumn do MSSQL). Polecam garść artykułów na ten temat:

http://www.sqlskills.com/BLOGS/PAUL/category/Sparse-Columns.aspx

Jeśli nie stosujesz MSSQL2008 to potraktuj mojego posta w kategorii "nie zawsze postępuj zgodnie z podręcznikami napisanymi 30 lat temu" ;-)

@AdamPL
Dzieki wielkie za pomoc

@tjj
Niestety uzywam MS SQL 2005
ale dobrze wiedziec ze istnieje cos takiego w 2008