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ę:



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

Pozdrawiam i Wesołych Świąt

Poradzić to baza sobie poradzi.

W kwestii optymalizacji pozakładaj odpowiednie klucze między tabelami co znacznie usprawni pobieranie wyników po ich połączeniu.

W kwestii sensowności jest to sensowne, bo nie zawężasz funkcjonalności, ale weź też poprawkę na to czy napewno jest to niezbędne i czy użytkownicy zrozumieją twoje intencje i się nie będą gubić w konfiguracji

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ę.

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:

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.... ?

Uniwersalnego sposobu wydaje mi się, że nie ma Zawsze będa jakieś plusy / minusy. Można zrobić jeszcze coś w stylu ez.. czyli np mamy tabele, która zawiera pola w stylu:

id serial, typ_produktu_id int, produkt_id int, f1 text, f2 text, f3 int, f4 int, f5 int, f6 int, f7 float, f8 float, f9 float, f10 float, f11 bool, f12 bool, f13 bool, f14 bool

minusem tego rozwiązania jest to, że ilość parametrów opisujących produkt jest ograniczona i do tego jest ograniczona liczba typów, chodź w sumie można zrobić też dużą ilość varchar i wykorzystywać zamiast float czy int czy nawet bool

Uhuhu chyba ktoś zapomniał o nazwie producenta

No i w kategoriach oczywiście parent_id do zaimplementowania wielopoziomowej struktury kategorii, nawet jeżeli w tej chwili jej nie ma to na 100% za jakiś czas będzie

Oczywiście że będą inne cechy w tabeli produkty no i parent w kategoriach to jest na razie szkic...

Może ktoś powiedzieć czy baza PostgreSQL ma jakieś limity?? Tak jak pisałem wcześniej jeśli w cechy_wartosci będzie powiedzmy 10mln rekordów to czy nie zapcha to bazy?

nie powinno, żeby to sprawdzić wystarczy 5 minut, utwórz tabelę i wypełniaj danymi INSERT ... SELECT ... LIMIT 100000

troche za szybko ten temat sie skonczyl:)
musze odgrzebac bo mam takie pytanie

w panelu admina jest dodawanie produktow - wypiszesz wszystkie dostepne cechy?

czy raczej jest jeszcze dodatkowa tabela
chechy_kategorie: kategoria_id, cecha_id