Entity Attribute Value Database vs. strikter relationaler Modell-E-Commerce

Man kann mit Sicherheit sagen, dass das EAV / CR- Datenbankmodell schlecht ist. Das gesagt,

Frage: Welches Datenbankmodell, welche Datenbanktechnik oder welches Datenbankmuster sollte verwendet werden, um mit "Klassen" von Attributen umzugehen, die E-Commerce-Produkte beschreiben, die zur Laufzeit geändert werden können?

In einer guten E-Commerce-Datenbank speichern Sie Klassen von Optionen (z. B. TV-Auflösung, dann eine Auflösung für jedes Fernsehgerät, aber das nächste Produkt ist möglicherweise kein Fernsehgerät und hat keine "TV-Auflösung"). Wie speichern Sie sie, suchen effizient und ermöglichen Ihren Benutzern, Produkttypen mit variablen Feldern einzurichten, die ihre Produkte beschreiben? Wenn die Suchmaschine feststellt, dass Kunden normalerweise nach Fernsehgeräten suchen, die auf der Konsolentiefe basieren, können Sie Ihren Feldern Konsolentiefe hinzufügen und dann zur Laufzeit für jeden TV-Produkttyp eine einzige Tiefe hinzufügen.

Gute E-Commerce-Apps haben eine nette gemeinsame Funktion, bei der sie eine Reihe von Produkten anzeigen. Dann gibt es "Drilldown" -Seitenmenüs, in denen Sie "TV-Auflösung" als Kopfzeile sehen können, und die fünf häufigsten TV-Auflösungen für die Set gefunden. Wenn Sie auf eines klicken, werden nur Fernsehgeräte mit dieser Auflösung angezeigt, sodass Sie einen weiteren Drilldown durchführen können, indem Sie im Seitenmenü andere Kategorien auswählen. Diese Optionen sind die dynamischen Produktattribute, die zur Laufzeit hinzugefügt werden.

Weitere Diskussion:

So lange Rede, kurzer Sinn, gibt es im Internet Links oder Modellbeschreibungen, die das folgende Setup "akademisch" beheben könnten? Ich danke Noel Kennedy für den Vorschlag einer Kategorietabelle, aber der Bedarf ist möglicherweise größer. Ich beschreibe es unten anders und versuche, die Bedeutung hervorzuheben. Möglicherweise benötige ich eine Blickwinkelkorrektur, um das Problem zu lösen, oder ich muss mich eingehender mit dem EAV / CR befassen.

Ich liebe die positive Resonanz auf das EAV / CR-Modell. Meine Entwicklerkollegen sagen alle, was Jeffrey Kemp unten angesprochen hat: "Neue Entitäten müssen von einem Fachmann modelliert und entworfen werden" (aus dem Zusammenhang gerissen, lesen Sie seine Antwort unten). Das Problem ist:

• Entitäten fügen wöchentlich Attribute hinzu und entfernen sie
  (Suchschlüsselwörter bestimmen zukünftige Attribute)
• Wöchentlich kommen neue Einheiten hinzu
  (Produkte werden aus Teilen zusammengesetzt).
• alte Entitäten verschwinden wöchentlich
  (archiviert, weniger beliebt, saisonal)

Der Kunde möchte den Produkten aus zwei Gründen Attribute hinzufügen:

• Abteilungs- / Stichwortsuche / Vergleichstabelle zwischen ähnlichen Produkten
• Konfiguration des Verbraucherprodukts vor dem Auschecken

Die Attribute müssen eine Bedeutung haben, nicht nur eine Stichwortsuche. Wenn sie alle Kuchen vergleichen möchten, die einen "Schlagsahne-Zuckerguss" haben, können sie auf Kuchen klicken, auf das Geburtstagsthema klicken, auf Schlagsahne-Zuckerguss klicken und dann alle Kuchen überprüfen, die interessant sind, da sie alle Schlagsahne-Zuckerguss haben. Dies ist nicht spezifisch für Kuchen, nur ein Beispiel.

Es gibt ein paar allgemeine Vor- und Nachteile, die mir einfallen, es gibt Situationen, in denen einer besser ist als der andere:

Option 1, EAV-Modell:

• Pro: weniger Zeit zum Entwerfen und Entwickeln einer einfachen Anwendung
• Pro: Neue Entitäten einfach hinzuzufügen (möglicherweise sogar von Benutzern hinzugefügt?)
• Pro: "generische" Schnittstellenkomponenten
• Con: Komplexer Code zur Validierung einfacher Datentypen erforderlich
• Con: viel komplexeres SQL für einfache Berichte
• Con: Komplexe Berichte können fast unmöglich werden
• Con: schlechte Leistung für große Datenmengen

Option 2, Modellierung jeder Entität separat:

• Con: Mehr Zeit erforderlich, um Anforderungen und Design zu erfassen
• Con: Neue Entitäten müssen von einem Fachmann modelliert und entworfen werden
• Con: Benutzerdefinierte Schnittstellenkomponenten für jede Entität
• Pro: Datentypeinschränkungen und Validierung einfach zu implementieren
• Pro: SQL ist einfach zu schreiben, leicht zu verstehen und zu debuggen
• Pro: Selbst die komplexesten Berichte sind relativ einfach
• Pro: Beste Leistung für große Datenmengen

Option 3, Kombination (Modellentitäten "richtig", aber "Erweiterungen" für benutzerdefinierte Attribute für einige / alle Entitäten hinzufügen)

• Pro / Con: Mehr Zeit zum Sammeln von Anforderungen und Design als bei Option 1, aber möglicherweise nicht so viel wie bei Option 2 *
• Con: Neue Entitäten müssen von einem Fachmann modelliert und entworfen werden
• Pro: Neue Attribute können später leicht hinzugefügt werden
• Con: Komplexer Code zur Validierung einfacher Datentypen (für die benutzerdefinierten Attribute)
• Con: Benutzerdefinierte Schnittstellenkomponenten sind weiterhin erforderlich, für die benutzerdefinierten Attribute sind jedoch möglicherweise generische Schnittstellenkomponenten möglich
• Con: SQL wird komplex, sobald ein benutzerdefiniertes Attribut in einem Bericht enthalten ist
• Con: Gute Leistung im Allgemeinen, es sei denn, Sie müssen nach benutzerdefinierten Attributen suchen oder Berichte erstellen

* Ich bin mir nicht sicher, ob Option 3 in der Entwurfsphase unbedingt Zeit sparen würde.

Persönlich würde ich mich zu Option 2 neigen und EAV nach Möglichkeit vermeiden. Für einige Szenarien benötigen die Benutzer jedoch die Flexibilität, die mit EAV einhergeht. Dies ist jedoch mit hohen Kosten verbunden.

Man kann mit Sicherheit sagen, dass das EAV / CR-Datenbankmodell schlecht ist.

Nein, ist es nicht. Es ist nur so, dass sie eine ineffiziente Nutzung relationaler Datenbanken sind. Ein reiner Schlüssel- / Wertspeicher funktioniert mit diesem Modell hervorragend.

Nun zu Ihrer eigentlichen Frage: Wie können verschiedene Attribute gespeichert und durchsuchbar gehalten werden?

Verwenden Sie einfach EAV. In Ihrem Fall wäre es eine einzelne zusätzliche Tabelle. Indizieren Sie es sowohl nach dem Attributnamen als auch nach dem Wert. Die meisten RDBMs verwenden die Präfixkomprimierung für die Wiederholungen des Attributnamens, wodurch es sehr schnell und kompakt wird.

EAV / CR wird hässlich, wenn Sie damit "echte" Felder ersetzen. Wie bei jedem Tool ist eine Überbeanspruchung "schlecht" und verleiht ihm ein schlechtes Image.

// An dieser Stelle möchte ich mir einen Moment Zeit nehmen, um mit Ihnen über das Magento / Adobe PSD-Format zu sprechen .
// Magento / PSD ist keine gute E-Commerce-Plattform / Format . Magento / PSD ist nicht einmal eine schlechte E-Commerce-Plattform / ein schlechtes E-Commerce- Format . Es so zu nennen wäre ein
// Beleidigung anderer schlechter E-Commerce-Plattformen / -Formate wie Zencart oder OsCommerce. Nein, Magento / PSD ist eine miserable E-Commerce-Plattform / -Format . Haben
// habe seit einigen Wochen an diesem Code gearbeitet, mein Hass auf Magento / PSD hat sich zu einem wütenden Feuer entwickelt
// das brennt mit der heftigen Leidenschaft von einer Million Sonnen.

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

Die internen Modelle sind bestenfalls verrückt, als hätte jemand das Schema in ein Boggle-Spiel gesteckt, es versiegelt und in einen Farb-Shacker gesteckt ...

Reale Welt: Ich arbeite an einer Midware-Fulfillment-App und hier ist eine der Fragen, um Adressinformationen zu erhalten.

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'

Genaue Adressinformationen für eine Bestellung, träge

- -

Zusammenfassung: Verwenden Sie Magento nur, wenn:

1. Sie bekommen große Säcke Geld
2. Du musst
3. Genieße den Schmerz

Ich bin überrascht, dass niemand NoSQL-Datenbanken erwähnt hat.

Ich habe NoSQL noch nie in einem Produktionskontext geübt (habe gerade MongoDB getestet und war beeindruckt), aber der springende Punkt bei NoSQL ist, Elemente mit unterschiedlichen Attributen in demselben "Dokument" speichern zu können.

Wenn die Leistung keine Hauptanforderung ist, wie bei einer ETL-Anwendung, hat EAV einen weiteren entscheidenden Vorteil: differenzielle Einsparungen.

Ich habe eine Reihe von Anwendungen implementiert, bei denen eine übergreifende Anforderung darin bestand, den Verlauf eines Domänenobjekts von seiner ersten "Version" bis zu seinem aktuellen Status anzuzeigen. Wenn dieses Domänenobjekt eine große Anzahl von Attributen aufweist, bedeutet dies, dass für jede Änderung eine neue Zeile in die entsprechende Tabelle eingefügt werden muss (keine Aktualisierung, da der Verlauf verloren gehen würde, sondern eine Einfügung). Angenommen, dieses Domänenobjekt ist eine Person, und ich muss 500.000 Personen mit durchschnittlich mehr als 100 Änderungen im Lebenszyklus der Person an verschiedenen Attributen verfolgen. Kombinieren Sie dies mit der Tatsache, dass die Anwendung mit nur einem Hauptdomänenobjekt selten ist, und Sie werden schnell vermuten, dass die Größe der Datenbank schnell außer Kontrolle geraten würde.

Eine einfache Lösung besteht darin, nur die unterschiedlichen Änderungen an den Hauptdomänenobjekten zu speichern, anstatt wiederholt redundante Informationen zu speichern.

Alle Modelle ändern sich im Laufe der Zeit, um neuen Geschäftsanforderungen Rechnung zu tragen. Zeitraum. Die Verwendung von EAV ist nur eines der Tools in unserer Box. aber es sollte niemals automatisch als "schlecht" eingestuft werden.

Ich kämpfe mit dem gleichen Problem. Es kann für Sie interessant sein, die folgende Diskussion über zwei vorhandene E-Commerce-Lösungen zu lesen: Magento (EAV) und Joomla (reguläre relationale Struktur): https://forum.virtuemart.net/index.php?topic=58686.0

Es scheint, dass die EAV-Leistung von Magento ein echter Showstopper ist.

Deshalb neige ich zu einer normalisierten Struktur. Um den Mangel an Flexibilität zu überwinden, denke ich darüber nach, in Zukunft ein separates Datenwörterbuch (XML oder separate DB-Tabellen) hinzuzufügen, das bearbeitet werden könnte. Auf dieser Grundlage würde Anwendungscode zum Anzeigen und Vergleichen von Produktkategorien mit neuen Attributen festgelegt zusammen mit SQL-Skripten generiert.

Eine solche Architektur scheint in diesem Fall der Sweetspot zu sein - flexibel und performant zugleich.

Das Problem könnte die häufige Verwendung von ALTER TABLE in Live-Umgebungen sein. Ich verwende Postgres, daher werden MVCC und Transaktions-DDL hoffentlich die Schmerzen lindern.

Ich stimme immer noch für die Modellierung auf der niedrigstwertigen atomaren Ebene für EAV. Lassen Sie Standards, Technologien und Anwendungen, die sich an bestimmte Benutzergemeinschaften richten, über Inhaltsmodelle, Wiederholungsanforderungen von Attributen, Körnern usw. entscheiden.

Wenn es nur um die Produktkatalogattribute geht und daher die Validierungsanforderungen für diese Attribute eher begrenzt sind, ist der einzige wirkliche Nachteil von EAV die Abfrageleistung, und selbst das ist nur dann ein Problem, wenn Ihre Abfrage mehrere "Dinge" (Produkte) mit Attributen behandelt. Die Leistung für die Abfrage "Geben Sie mir alle Attribute für das Produkt mit der ID 234", obwohl sie nicht optimal ist, ist immer noch schnell genug.

Eine Lösung besteht darin, das SQL-Datenbank- / EAV-Modell nur für die Administrator- / Bearbeitungsseite des Produktkatalogs zu verwenden und über einen Prozess zu verfügen, der die Produkte in etwas denormalisiert, das sie durchsuchbar macht. Da Sie bereits Attribute haben und daher eher Facettieren möchten, kann dies Solr oder ElasticSearch sein. Dieser Ansatz vermeidet grundsätzlich alle Nachteile des EAV-Modells und die zusätzliche Komplexität beschränkt sich auf die Serialisierung eines vollständigen Produkts in JSON beim Update.

EAV hat viele Nachteile:

1. Leistungsabfall im Laufe der Zeit Sobald die Datenmenge in der Anwendung eine bestimmte Größe überschreitet, wird das Abrufen und Bearbeiten dieser Daten wahrscheinlich immer weniger effizient.
2. Die SQL-Abfragen sind sehr komplex und schwer zu schreiben.
3. Datenintegritätsprobleme. Sie können nicht für alle benötigten Felder Fremdschlüssel definieren.
4. Sie müssen Ihre eigenen Metadaten definieren und pflegen.

Ich habe ein etwas anderes Problem: Anstelle vieler Attribute mit spärlichen Werten (was möglicherweise ein guter Grund ist, EAV zu verwenden) möchte ich etwas mehr wie eine Tabelle speichern. Die Spalten im Blatt können sich ändern, aber innerhalb eines Blattes enthalten alle Zellen Daten (nicht dünn).

Ich habe eine kleine Reihe von Tests gemacht um zwei Designs zu vergleichen: eines mit EAV und das andere mit einem Postgres ARRAY zum Speichern von Zelldaten.

EAV

Array

Beide Schemas haben Indizes für entsprechende Spalten, und die Indizes werden vom Planer verwendet.

Es stellte sich heraus, dass das Array-basierte Schema sowohl für Einfügungen als auch für Abfragen um eine Größenordnung schneller war . Aus schnellen Tests ging hervor, dass beide linear skalierten. Die Tests sind jedoch nicht sehr gründlich. Vorschläge und Gabeln sind willkommen - sie stehen unter einer MIT-Lizenz.