Problem z zaprojektowaniem bazy, sklep Opcje

[jasina]

Witam serdecznie
Właśnie tworzę sklep internetowy i nie wiem jaką bazę danych utworzyć.

Zakładam, że nie wiem kto będzie korzystał ze sklepu także muszę wziąć pod uwagę, że w sklepie będzie powiedzmy 200 000 różnych produktów w 100 kategoriach (czysto teoretycznie) i problem rodzi się w momencie dodawania produktów do bazy, bo przecież "Laptopy" mają inne cechy niż "Aparaty cyfrowe".
Czytając forum doszedłem do wniosku, że można by zrobić taką strukturę:

TABELA PRODUKTY
produkt_id
kategoria_id
produkt_nazwa
produkt_cena
produkt_opis
i ewentualnie jakieś cechy wspólne

TABELA CECHY
cecha_id
kategoria_id
cecha_nazwa
cecha_typ_danych

TABELA CECHY_WARTOSCI
wartosc_id
cecha_id
produkt_id
wartosc_napis (string[255])
wartosc_liczba (real)

TABELA KATEGORIE
kategoria_id
kategoria_nazwa

Wydaje mi się (ale nie jestem tego pewien), że to rozwiązanie zda egzamin z punktu widzenia elastyczności sklepu ale nie wiem czy będzie to rozwiązanie wydajne przy większej ilości kategorii (z różnymi cechami).

Powiedzmy, że średnio 1 kategoria dla sklepu ze sprzętem elektronicznym ma 15 cech. Gdy produktów będzie 100 000 to w tabeli CECHY_WARTOSCI pojawi się 100 000*15=1 500 000 rekordów i tutaj już zaczyna się robić problem bo nie wiem czy baza PostgreSQL lub MySQL (raczej będę używał PostgreSQL) poradzi sobie z taką dużą ilością danych przy bardzo skomplikowanych zapytaniach (join)?

Dlatego myślałem czy nie warto zrobić sklepu najpierw planując jakie będą kategorie i dla każdej kategorii stworzyć osobną tabelę z cechami (np 15 kolumnową).
To może i byłoby wydajniejsze ale z drugiej strony posiadanie 100 tabeli w bazie (a może więcej) i tworzenie ich dla każdej nowej kategorii wydaj mi się bez sensu.


Czekam na jakieś kreatywne sugestie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Pozdrawiam i Wesołych Świąt

[jasina]

Czy nie lepszym rozwiązaniem zamiast dodawania poszczególnych wartości cech w tabeli CECHY_WARTOSCI byłoby dodawanie tylko 1 rekordu dla 1 produktu w formie zserializowanej tablicy?
Ograniczyło by to liczbę (mogącą dojść nawet do x milionów) rekordów w tablicy ale ograniczyłoby możliwości przeszukiwania bazy produktów biorąc pod uwagę poszczególne cechy...........

[sf]

Czy nie lepszym rozwiązaniem zamiast dodawania poszczególnych wartości cech w tabeli CECHY_WARTOSCI byłoby dodawanie tylko 1 rekordu dla 1 produktu w formie zserializowanej tablicy?
Ograniczyło by to liczbę (mogącą dojść nawet do x milionów) rekordów w tablicy ale ograniczyłoby możliwości przeszukiwania bazy produktów biorąc pod uwagę poszczególne cechy...........

Zależy. Jeśli bardzo zależy nam na elatyczności, usuwaniu, dodawaniu atrybutów to pojawia się problem co jeśli np. z laptopów wyrzucimy jakiś parametr, albo zmienmy go na jakiś inny... jak zaktualizujemy te dane w tablicy serializowanej? Będzie trzeba napisać skrypt, który to pozamienia. Babranina!

Taką serializowaną tablicę można użyć, ale jako dodatek, cache, który jest generowany raz na jakiś czas. Dane trzymane są tak jak przedstawiono to wyżej. Dzięki temu przy użytkowaniu mamy elastyczną bazę i wydajny system.

Optymalizacja nie powinna się przekładać na źle skonstruowaną bazę.

[jasina]

Zależy. Jeśli bardzo zależy nam na elatyczności, usuwaniu, dodawaniu atrybutów to pojawia się problem co jeśli np. z laptopów wyrzucimy jakiś parametr, albo zmienmy go na jakiś inny... jak zaktualizujemy te dane w tablicy serializowanej? Będzie trzeba napisać skrypt, który to pozamienia. Babranina!

Taką serializowaną tablicę można użyć, ale jako dodatek, cache, który jest generowany raz na jakiś czas. Dane trzymane są tak jak przedstawiono to wyżej. Dzięki temu przy użytkowaniu mamy elastyczną bazę i wydajny system.

Optymalizacja nie powinna się przekładać na źle skonstruowaną bazę.

Co racja to racja ale nadal mam obawy przed stosowaniem pierwszego rozwiązania......
Bo przecież jak w sklepie będzie 1mln produktów to w tabeli CECHY_WARTOSCI będzie taki tłok ze szkoda gadać - będzie pewnie z 15 mln (!) rekordów (?).
Poza tym:

TABELA CECHY_WARTOSCI
wartosc_id
cecha_id
produkt_id
wartosc_napis (string[255])
wartosc_liczba (real)

Mamy przecież różne cechy niektóre to będzie np. "tak/nie", "brak", może jakiś dłuższy opis i to chcialem przechowywać w string[255] a jeśli będzie na przykład pojemność dysku twardego "80" (w gb) lub przekątna ekranu "21.3" w calach to będe przechowywał w wartość_napis czyli jako real.
Rodzi się pytanie czy nie lepiej stworzyć osobną tabelę dla cech typu liczba i cech typu napis bo przecież w mojej strukturze połowa pól będzie pusta.... ?