Baza danych wartości atrybutów encji a e-commerce na podstawie ścisłego modelu relacyjnego

Można śmiało powiedzieć, że model bazy danych EAV / CR jest zły. To mówi,

Pytanie: Jaki model, technika lub wzorzec bazy danych należy zastosować w przypadku „klas” atrybutów opisujących produkty handlu elektronicznego, które można zmienić w czasie wykonywania?

W dobrej bazie danych handlu elektronicznego będziesz przechowywać klasy opcji (np. Rozdzielczość telewizora, a następnie rozdzielczość każdego telewizora, ale następny produkt może nie być telewizorem i nie mieć „rozdzielczości telewizyjnej”). Jak je przechowywać, efektywnie wyszukiwać i pozwalać użytkownikom konfigurować typy produktów za pomocą zmiennych pól opisujących ich produkty? Jeśli wyszukiwarka stwierdzi, że klienci zazwyczaj szukają telewizorów na podstawie głębokości konsoli, możesz dodać głębokość konsoli do swoich pól, a następnie dodać po jednej głębokości dla każdego typu telewizora w czasie wykonywania.

Dobre aplikacje do handlu elektronicznego mają fajną wspólną cechę, w której pokazują zestaw produktów, a następnie mają „szczegółowe” menu boczne, w których można zobaczyć „Rozdzielczość TV” jako nagłówek, oraz pięć najpopularniejszych rozdzielczości telewizyjnych dla znaleziony zestaw. Po kliknięciu jednego z nich wyświetla się tylko telewizory o tej rozdzielczości, umożliwiając dalsze przeglądanie, wybierając inne kategorie w menu bocznym. Te opcje to dynamiczne atrybuty produktu dodane w czasie wykonywania.

Dalsza dyskusja:

Krótko mówiąc, czy w Internecie są jakieś linki lub opisy modeli, które mogłyby „naukowo” naprawić następującą konfigurację? Dziękuję Noelowi Kennedy'emu za zasugerowanie tabeli kategorii, ale potrzeba może być większa. Poniżej opisuję to inaczej, starając się podkreślić znaczenie. Być może potrzebuję korekty punktu widzenia, aby rozwiązać problem, lub może być konieczne zgłębienie głębiej do EAV / CR.

Uwielbiam pozytywną reakcję na model EAV / CR. Moi koledzy programiści mówią o tym, o czym Jeffrey Kemp poruszył poniżej: „nowe jednostki muszą być modelowane i projektowane przez profesjonalistę” (wyrwane z kontekstu, przeczytaj jego odpowiedź poniżej). Problemem jest:

• encje dodają i usuwają atrybuty co tydzień
  (słowa kluczowe wyszukiwania dyktują przyszłe atrybuty)
• nowe jednostki przybywają co tydzień
  (produkty są składane z części)
• stare elementy znikają co tydzień
  (archiwizowane, mniej popularne, sezonowe)

Klient chce dodać atrybuty do produktów z dwóch powodów:

• wyszukiwanie działów / słów kluczowych / tabela porównawcza podobnych produktów
• konfiguracja produktu konsumenckiego przed zakupem

Atrybuty muszą mieć znaczenie, a nie tylko wyszukiwanie słów kluczowych. Jeśli chcą porównać wszystkie ciasta, które mają „lukier z bitej śmietany”, mogą kliknąć ciasta, kliknąć motyw urodzinowy, kliknąć lukier z bitej śmietany, a następnie sprawdzić wszystkie interesujące ciasta, wiedząc, że wszystkie mają lukier z bitej śmietany. To nie jest specyficzne dla ciast, tylko przykład.

Jest kilka ogólnych za i przeciw, które przychodzą mi do głowy, są sytuacje, w których jeden jest lepszy od drugiego:

Opcja 1, model EAV:

• Zaleta: mniej czasu na zaprojektowanie i opracowanie prostej aplikacji
• Pro: nowe encje łatwe do dodania (mogą nawet zostać dodane przez użytkowników?)
• Pro: „ogólne” komponenty interfejsu
• Wada: złożony kod wymagany do walidacji prostych typów danych
• Wada: dużo bardziej złożony SQL dla prostych raportów
• Wada: złożone raporty mogą stać się prawie niemożliwe
• Wada: słaba wydajność w przypadku dużych zestawów danych

Opcja 2, modelowanie każdego podmiotu osobno:

• Wada: więcej czasu potrzeba na zebranie wymagań i projektu
• Wada: nowe jednostki muszą być modelowane i projektowane przez profesjonalistę
• Wada: niestandardowe komponenty interfejsu dla każdej jednostki
• Pro: ograniczenia typu danych i walidacja proste do wdrożenia
• Pro: SQL jest łatwy do napisania, łatwy do zrozumienia i debugowania
• Zaleta: nawet najbardziej złożone raporty są stosunkowo proste
• Pro: najlepsza wydajność dla dużych zestawów danych

Opcja 3, kombinacja (modelowanie jednostek „prawidłowo”, ale dodaj „rozszerzenia” dla atrybutów niestandardowych dla niektórych / wszystkich jednostek)

• Pro / Con: więcej czasu potrzeba na zebranie wymagań i projektu niż opcja 1, ale być może nie tak dużo jak opcja 2 *
• Wada: nowe jednostki muszą być modelowane i projektowane przez profesjonalistę
• Pro: nowe atrybuty można łatwo dodać później
• Wada: złożony kod wymagany do walidacji prostych typów danych (dla atrybutów niestandardowych)
• Wada: niestandardowe komponenty interfejsu są nadal wymagane, ale dla atrybutów niestandardowych mogą być dostępne ogólne komponenty interfejsu
• Wada: SQL staje się złożony, gdy tylko jakikolwiek atrybut niestandardowy zostanie uwzględniony w raporcie
• Wada: ogólnie dobra wydajność, chyba że musisz rozpocząć wyszukiwanie lub raportowanie według atrybutów niestandardowych

* Nie jestem pewien, czy opcja 3 koniecznie pozwoliłaby zaoszczędzić czas na etapie projektowania.

Osobiście skłaniałbym się ku opcji 2 i unikał EAV, gdy tylko jest to możliwe. Jednak w niektórych scenariuszach użytkownicy potrzebują elastyczności, która zapewnia EAV; ale wiąże się to z dużymi kosztami.

Można śmiało powiedzieć, że model bazy danych EAV / CR jest zły.

Nie, nie jest. Chodzi tylko o to, że są one nieefektywnym wykorzystaniem relacyjnych baz danych. W tym modelu świetnie sprawdza się czysty magazyn kluczy / wartości.

A teraz do twojego prawdziwego pytania: jak przechowywać różne atrybuty i umożliwić ich przeszukiwanie?

Po prostu użyj EAV. W twoim przypadku byłby to pojedynczy dodatkowy stół. indeksuj go zarówno pod względem nazwy, jak i wartości, większość RDBM użyje kompresji przedrostków do powtórzeń nazw atrybutów, dzięki czemu jest naprawdę szybki i zwarty.

EAV / CR staje się brzydki, gdy używasz go do zastąpienia „prawdziwych” pól. Jak w przypadku każdego narzędzia, jego nadużywanie jest „złe” i daje zły obraz.

// W tym miejscu chciałbym poświęcić chwilę, aby porozmawiać z tobą o Magento / formacie Adobe PSD .
// Magento / PSD nie jest dobrą platformą / formatem e-commerce . Magento / PSD nie jest nawet złą platformą e-commerce / formatem . Nazywanie tego tak byłoby
// obrażanie innych złych platform / formatów e-commerce , takich jak Zencart lub OsCommerce. Nie, Magento / PSD to fatalna platforma e-commerce / format . Mający
// pracowałem nad tym kodem już od kilku tygodni, moja nienawiść do Magento / PSD przerodziła się w szalejący ogień
// który płonie zaciekłą pasją miliona słońc.

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

Modele wewnętrzne są w najlepszym razie zwariowane, jakby ktoś włożył schemat do głupiej gry, zapieczętował to i włożył do shakera z farbą ...

Prawdziwy świat: Pracuję nad aplikacją do realizacji oprogramowania pośredniego i oto jedno z pytań, aby uzyskać informacje adresowe.

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

Dokładne dane adresowe do zamówienia, leniwie

-

Podsumowanie: Używaj Magento tylko wtedy, gdy:

1. Dostajesz duże worki pieniędzy
2. Musisz
3. Ciesz się bólem

Dziwię się, że nikt nie wspomniał o bazach danych NoSQL.

Nigdy nie ćwiczyłem NoSQL w kontekście produkcyjnym (właśnie przetestowałem MongoDB i byłem pod wrażeniem), ale głównym celem NoSQL jest możliwość zapisywania elementów o różnych atrybutach w tym samym „dokumencie”.

Tam, gdzie wydajność nie jest głównym wymaganiem, jak w przypadku aplikacji typu ETL, EAV ma inną wyraźną zaletę: różnicowe oszczędności.

Zaimplementowałem wiele aplikacji, w których nadrzędnym wymogiem była możliwość przeglądania historii obiektu domeny od jego pierwszej „wersji” do aktualnego stanu. Jeśli ten obiekt domeny ma dużą liczbę atrybutów, oznacza to, że każda zmiana wymaga wstawienia nowego wiersza do odpowiedniej tabeli (nie aktualizacji, ponieważ historia zostałaby utracona, ale wstawienie). Załóżmy, że ten obiekt domeny to Osoba i mam 500 tys. Osób do śledzenia ze średnio ponad 100 zmianami różnych atrybutów w cyklu życia Osoby. Połącz to z faktem, że rzadka jest aplikacja, która ma tylko 1 główny obiekt domeny, a szybko przypuszczasz, że rozmiar bazy danych szybko wymknie się spod kontroli.

Łatwym rozwiązaniem jest zapisanie tylko zmian różnicowych w głównych obiektach domeny zamiast wielokrotnego zapisywania nadmiarowych informacji.

Wszystkie modele zmieniają się z czasem, aby odzwierciedlić nowe potrzeby biznesowe. Kropka. Używanie EAV to tylko jedno z narzędzi dostępnych w naszym pudełku; ale nigdy nie powinien być automatycznie klasyfikowany jako „zły”.

Zmagam się z tym samym problemem. Może Cię zainteresować poniższa dyskusja na temat dwóch istniejących rozwiązań e-commerce: Magento (EAV) i Joomla (zwykła struktura relacyjna): https://forum.virtuemart.net/index.php?topic=58686.0

Wygląda na to, że wydajność EAV Magento jest prawdziwym hitem.

Dlatego skłaniam się ku znormalizowanej strukturze. Aby przezwyciężyć brak elastyczności, myślę o dodaniu w przyszłości oddzielnego słownika danych (XML lub oddzielne tabele DB), który można by edytować i na tej podstawie kod aplikacji do wyświetlania i porównywania kategorii produktów z nowym zestawem atrybutów byłby generowane wraz ze skryptami SQL.

Taka architektura wydaje się w tym przypadku słodka - elastyczna i jednocześnie performatywna.

Problemem może być częste używanie ALTER TABLE w środowisku na żywo. Używam Postgres, więc mam nadzieję, że jego MVCC i transakcyjny DDL złagodzą ból.

Nadal głosuję za modelowaniem na najniższym znaczącym poziomie atomowym dla EAV. Pozwól standardom, technologiom i aplikacjom, które kierują się w stronę określonej społeczności użytkowników, decydować o modelach treści, potrzebach powtarzania atrybutów, ziarnistości itp.

Jeśli chodzi tylko o atrybuty katalogu produktów, a zatem wymagania dotyczące walidacji tych atrybutów są raczej ograniczone, jedyną prawdziwą wadą EAV jest wydajność zapytań, a nawet to jest tylko problem, gdy zapytanie dotyczy wielu „rzeczy” (produktów) z atrybutami, wykonanie zapytania „podaj wszystkie atrybuty produktu o identyfikatorze 234”, mimo że nie jest optymalne, jest nadal bardzo szybkie.

Jednym z rozwiązań jest użycie modelu bazy danych SQL / EAV tylko po stronie administratora / edycji katalogu produktów i zastosowanie pewnego procesu denormalizującego produkty w coś, co umożliwia ich przeszukiwanie. Ponieważ masz już atrybuty i dlatego jest raczej prawdopodobne, że chcesz facetingu, to może być Solr lub ElasticSearch. Takie podejście pozwala uniknąć w zasadzie wszystkich wad modelu EAV, a dodatkowa złożoność ogranicza się do serializacji całego produktu do formatu JSON podczas aktualizacji.

EAV ma wiele wad:

1. Spadek wydajności z upływem czasu Gdy ilość danych w aplikacji przekroczy pewien rozmiar, pobieranie i manipulowanie tymi danymi będzie prawdopodobnie coraz mniej wydajne.
2. Zapytania SQL są bardzo złożone i trudne do napisania.
3. Problemy z integralnością danych. Nie możesz zdefiniować kluczy obcych dla wszystkich potrzebnych pól.
4. Musisz zdefiniować i utrzymywać własne metadane.

Mam nieco inny problem: zamiast wielu atrybutów z rzadkimi wartościami (co jest prawdopodobnie dobrym powodem do korzystania z EAV), chcę przechowywać coś bardziej jak arkusz kalkulacyjny. Kolumny w arkuszu mogą się zmieniać, ale w arkuszu wszystkie komórki będą zawierały dane (nie są rzadkie).

Wykonałem mały zestaw testów, aby porównać dwa projekty: jeden wykorzystujący EAV, a drugi wykorzystujący Postgres ARRAY do przechowywania danych komórki.

EAV

Szyk

Oba schematy mają indeksy w odpowiednich kolumnach, a indeksy są używane przez planistę.

Okazało się, że schemat oparty na tablicy był o rząd wielkości szybszy zarówno w przypadku wstawiania, jak i zapytań. Z szybkich testów wydawało się, że oba skalowały się liniowo. Testy nie są jednak zbyt dokładne. Sugestie i widelce mile widziane - są objęte licencją MIT.