Baza danych atrybutów encji a ścisły Model relacyjny Ecommerce

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

Teraz, do twojego prawdziwego pytania: jak przechowywać różne atrybuty i zachować je do przeszukiwania?

EAV / CR staje się brzydki, gdy używasz go do zastępowania "prawdziwych" pól. Jak w przypadku każdego narzędzia, nadużywanie go jest " złe " i nadaje mu zły obraz.

// At this point, I'd like to take a moment to speak to you about the Magento/Adobe PSD format.
// Magento/PSD is not a good ecommerce platform/format. Magento/PSD is not even a bad ecommerce platform/format. Calling it such would be an
// insult to other bad ecommerce platform/formats, such as Zencart or OsCommerce. No, Magento/PSD is an abysmal ecommerce platform/format. Having
// worked on this code for several weeks now, my hate for Magento/PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.

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

Wewnętrzne modele są w najlepszym razie zwariowane, jakby ktoś włożył schemat do gry boggle, zapieczętował go i włożył do paint shacker...

Real world: pracuję nad aplikacją spełniającą wymagania midware i oto jedna z zapytań, aby uzyskać informacje o adresie.

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'

Pobiera dane adresowe do zamówienia, leniwie

--

Podsumowanie: używać tylko Magento if:

1. dostajesz duże worki pieniędzy
2. musisz
3. Enjoy pain

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

Nigdy nie ćwiczyłem NoSQL w kontekście produkcyjnym (po prostu testowałem MongoDB i byłem pod wrażeniem), ale chodzi o to, że NoSQL jest w stanie zapisywać elementy o różnych atrybutach w tym samym "dokumencie".

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

Zaimplementowałem wiele aplikacji, w których wymaganiem nadrzędnym była możliwość zobaczenia historii obiektu domeny od jego pierwszej "wersji" do jego aktualnego stanu. Jeśli 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 wkładka). Załóżmy, że ten obiekt domeny jest osobą, a ja mam 500k osób do śledzenia ze średnią 100 + zmian w cyklu życia osób do różnych atrybutów. Połącz to z faktem, że rzadko jest to aplikacja, która ma tylko główny obiekt domeny 1, A szybko podejrzewasz, że rozmiar bazy danych szybko wymknie się spod kontroli.

Łatwym rozwiązaniem jest zapisywanie tylko zmian różnicowych w głównych obiektach domeny, a nie wielokrotne zapisywanie zbędnych informacji.

Wszystkie modele zmieniają się w czasie, aby odzwierciedlić nowe potrzeby biznesowe. Kropka. Korzystanie z EAV jest tylko jednym z narzędzi w naszym pudełku, ale nigdy nie powinno być automatycznie klasyfikowane jako"złe".

Zmagam się z tym samym problemem. Może być dla Ciebie interesujące zapoznanie się z poniższą dyskusją na temat dwóch istniejących rozwiązań ecommerce: Magento (EAV) i Joomla (regularna struktura relacyjna): https://forum.virtuemart.net/index.php?topic=58686.0

Wydaje się, że EAV Magento jest prawdziwym showstopperem.

Dlatego skłaniam się ku znormalizowanej strukturze. Aby przezwyciężyć brak elastyczności, zastanawiam się nad dodaniem osobnych danych słownik w przyszłości (XML lub oddzielne tabele DB), który mógłby być edytowany, a na jego podstawie wygenerowany zostanie kod aplikacji do wyświetlania i porównywania kategorii produktów z nowymi ustawionymi atrybutami, wraz ze skryptami SQL.

Taka Architektura wydaje się być w tym przypadku słodkim punktem - elastycznym i wydajnym jednocześnie.

Problemem może być częste używanie ALTER TABLE w środowisku live. Korzystam z Postgres, więc jego MVCC i transactional DDL, mam nadzieję, że ułatwią ból.

Nadal głosuję za modelowaniem na najniższym poziomie atomowym dla EAV. Niech standardy, technologie i aplikacje, które przekładają się na pewną społeczność użytkowników do decydowania o modelach treści, potrzebach powtórzeń atrybutów, ziaren itp.

Jeśli chodzi tylko o atrybuty katalogu produktów, a tym samym wymagania walidacji dla tych atrybutów są raczej ograniczone, jedynym prawdziwym minusem EAV jest wydajność zapytań, a nawet to jest tylko problem, gdy zapytanie dotyczy wielu "rzeczy" (produktów) z atrybutami, wydajność dla zapytania "give me all attributes for the product with id 234" podczas gdy nie jest optymalna jest jeszcze dużo szybka.

Jednym z rozwiązań jest użycie modelu bazy danych SQL / EAV tylko dla administratora / Edytuj stronę katalogu produktów i wykonaj jakiś proces, który denormalizuje produkty w coś, co sprawia, że można je przeszukiwać. Ponieważ masz już atrybuty, a zatem jest raczej prawdopodobne, że chcesz fasetowania, to coś może być Solr lub ElasticSearch. Takie podejście pozwala uniknąć zasadniczo wszystkich wad modelu EAV, a dodatkowa złożoność ogranicza się do serializacji kompletnego produktu do JSON podczas aktualizacji.

EAV ma wiele wad:

[[3]}degradacja wydajności w czasie Gdy ilość danych w aplikacji przekroczy określony rozmiar, pobieranie i manipulowanie tymi danymi może stać się coraz mniej wydajne.
1. zapytania SQL są bardzo złożone i trudne do napisania.
Problemy z integralnością danych. Nie można zdefiniować kluczy obcych dla wszystkich wymaganych pól.
2. musisz zdefiniować i utrzymać własne metadane.

Mam nieco inny problem: zamiast wielu atrybutów z rzadkimi wartościami (co jest prawdopodobnie dobrym powodem do używania EAV), chcę zapisać 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).

Zrobiłem mały zestaw testów , aby porównać dwa projekty: jeden za pomocą EAV, a drugi za pomocą tablicy Postgres do przechowywania komórki data.

EAV

Array

Oba Schematy mają indeksy na 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 dla wstawek, jak i zapytań. Z szybkich testów wydawało się, że oba skalowane liniowo. Testy nie są zbyt dokładne. Propozycje i widelce mile widziane - są na licencji MIT.