Optymalna struktura bazy danych

0

Witam,
planuję właśnie strukturę bazy danych dla pewnej strony produktowej. Produktów będzie sporo, a dodatkowo każdy z nich będzie miał sporo atrybutów różnego typu dodawanych w sposób dynamiczny. Chciałbym aby zaprojektowana struktura była jak najbardziej optymalna przede wszystkim pod kątem efektownego poszukiwania produktu wg zdefiniowanej wartości atrybutu.

Myślałem nad takim układem:

db.jpg

Jednak taka struktura nie jest chyba zbyt optymalna... najwięcej zastrzeżeń mam do tabeli **attribute_value_description **i pola value, które jest polem tekstowym..
Skoro strona jest produktowa to na pewno będzie mnóstwo atrybutów numerycznych (np cena/waga/wymiary). Już na wstępie można zauważyć, że przeszukiwanie po tych polach będzie bardzo słabym pomysłem... Dla niewielu produktów ale dużej ilości unikalnych atrybutów ta tabela rozrośnie się to ogromnych rozmiarów.

Najprościej np cenę byłoby chyba przesunąć do głównej tabeli product, ale co z innymi atrybutami dodawanymi dynamicznie, po których ktoś np będzie chciał taką bazę przeszukiwać?

Będę bardzo wdzięczny za każdą sugestię/pomysł.

1

Ile będzie tych produktów i po ile będą miały atrybutów ?
Twoja struktura optymalna może i jest ale nazewnictwo bez sensu.
Ja bym zrobił tak:
screenshot-20200122181644.png

0

A może spróbujesz bazy, która obsługuje JSONa, np. PostgreSQL? Wtedy po prostu do produktu dodajesz pole typu JSON, a w środku jako klucza używasz ID atrybutu, a wartością jest... well, wartość atrybutu :D
Ewentualnie jakaś baza document-oriented typu MongoDB.

0

@katakrowa
Produktów +/- 50tys, natomiast do każdego z nich po około 100 atrybutów - większość będzie unikalna.

dodam jeszcze że w grę wchodzą wersje językowe - wtedy nazwa atrybutu i jego wartość może być inna dla danego języka...
pl: cena - 10PLN
en: price - 2USD
itp....

W Twojej wersji wartość atrybutu też jest wartością tekstową... A szukanie np produktów gdzie atrybut cena (liczba) jest większa niż jakaś wartość czy szukanie daty "większej niż" też chyba nie będzie zbyt optymalne?

1

Zerknij na strukturę jakiegoś istniejącego kodu sklepu, np sylius

https://github.com/Sylius/Sylius/tree/master/src/Sylius/Component/Product/Model
https://pastebin.com/EstQjHXh - ktoś zrobił dumpa nie wiem z jakiej wersji, ale prościej będzie Ci podejrzeć relacje

Pracowałem trochę na nim i bez problemu obsługiwał dziesiątki tysięcy produktów, włącznie z różnymi filtrami, poza tym zawiera też translatable dla produktów i waluty.

1

Nie wiem czy moje będzie optymalne bo prawie nic nie napisałeś poza tym, że będą produkty i atrybuty, w Twoje strukturze ceny też nie ma jest jedynie wzmianka w tekście. Nie wynika z niego czy cena jest uzależniona od atrybutu itp.. itd ... Jeśli produkt ma jedną cenę to nie ma co się zastanawiać i cena powinna być "przy produkcie".

I teraz kluczowe pytanie ... Po czym finalnie będziesz szukał bo skoro będziesz miał ~ kilka milionów unikalnych atrybutów ( 50 000 produktów * 100 unikalnych atrybutów ) to musisz to chyba jakoś usystematyzować ?

Generalnie nie ma rozwiązań szybkich i uniwersalnych ale są uniwersalne metodologie, które takie optymalne rozwiązania pozwalają zaprojektować.Im więcej informacji i założeń wypiszesz tym lepiej można zaprojektować bazę.
Zupełnie inaczej będzie wyglądała optymalna baza danych dla sklepu komputerowego, inaczej dla działu sprzedaży w hucie a jeszcze inaczej baza biura podróży. Każda z nich może mieć po kilka lub nawet kilkaset milionów rekordów, produkty także mają wiele atrybutów ale te wspólne cechy nie oznaczają, że da się dla nich wszystkich zaprojektować jedną optymalną strukturę bazy. Wynika to np, z tego, że:

  • czego innego dotyczą priorytety wyszukiwania ;
  • cena może być uzależniona od atrybutów / cech produktu ;
  • warunki wyszukiwania mogą być pytaniem nie tylko o produkt ale produkt w konkretnym "przekroju". Np w biurze podróży cena wycieczki zależy od wieku i ilości uczestników mimo, że to ten sam hotel, pokój i termin. To z kolei rzutuje na sposób wyszukiwania takich informacji oraz wymusza szczególne optymalizacje dla tego typu zadania.

Czasem projektując bazy dla nietypowych rozwiązań, nad trzema tabelkami co mają po 4 kolumny siedzimy po kilkanaście godzin zastanawiając się co lepiej z jakim typem, co indeksować czego nie ... Potem to implementujemy a po czasie dodajemy albo kasujemy jakąś tabelkę bo okazuje się, ze w praktyce tak jest bardziej optymalnie.

Zacznij od usystematyzowania rodzajów atrybutów:

  • liczbowe przeszukiwane po równości ;
  • liczbowe przeszukiwane po zakresach od - do ;
  • stringi, które można słownikować ;
  • stringi unikalne przeszukiwane tekstowo ;

Opisz dokładnie produkt

  • co to jest produkt ;
  • od czego zależy cena ;
  • co musi być wielojęzyczne ;
    itp .. itd ..

Oceń wymagania dla systemu.
Inne wymagania są dla wyszukiwarki na stronie internetowej a inne dla backoffice w małej firmie. Na stronie internetowej dostępnej publicznie czasy odpowiedzi "muszą" być dużo poniżej sekundy w przypadku backoffice czasy odpowiedzi około 3 sekund mogą nie stanowić problemu przy korzystaniu z systemu.

Przy ilościach o których piszesz być może optymalne będzie założyć więcej tabel wyspecjalizowanych do poszczególnych zadań stawianych przez warunki wyszukiwania.

0

@katakrowa
Twój post dał mi sporo do myślenia. Skoro faktycznie większość atrybutów będzie unikalna to po co po nich szukać....
Wyreparuję te, które będą się najczęściej powtarzały i po których będzie warto przeszukiwać bazę i przesunę je do głównej tabeli z produktem nadając im odpowiednie typy.

Chciałbym też poprosić Ciebie (lub kogoś innego) o wrzucenie struktur baz danych, które projektowane były w celu rozwiązania podobnego problemu. Głównie zależy mi aby było to najbardziej optymalnie rozwiązane.

0

Generalnie dobrym celem podczas projektowania bazy jest stworzenie słowników z wszystkich możliwych cech po których chcemy wyszukiwać. Wartości liczbowe wstawić do kolumn z odpowiednimi indeksami.
Z powyższego wynika, że należy podzielić dane ze względu na typ.:

  • liczby do tabel z liczbami liczb, najlepiej całkowite do całkowitych z floaty do floatów
  • stringi rozdzielić na te do których można zrobić słowniki i te które będziemy przeszukiwać tekstowo.

Wszystko po to by finalnie uzyskać możliwość zadawania pytań do bazy tak by szukać / porównywać tylko po indeksach i to bez konwertowania typów "w locie"/w trakcie wykonywania zapytania.
Jako ostateczność pozostawić przeszukiwanie po stringach ( szukanie typu like %% albo czy nawet searchtext ).

Przy dobrze zaprojektowanej bazie wyszukiwanie nawet po 10 000 000 rekordów nie jest kłopotem.

A w ogóle to najlepiej, żeby tabela po której wyszukujesz miała kolumny tylko typu integer i do RAM'u ją bo wtedy wyszukiwanie zapier..... cza. Czasem jednak to jest przesada. Sam musisz ocenić gdzie jest zdroworozsądkowa granica optymalizacji.

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