Ich habe schon eine Weile darüber nachgedacht, eine typische E-Commerce-Seite mit eBay-ähnlicher Taxonomie und Attributen zu modellieren, die von einer bestimmten Produktkategorie abhängen.
Der erste Versuch bestand darin, zwischen der EAV- und Tabellen-pro-Klasse-DB-Vererbungsmodellierung zu wählen. Ich habe letzteres wegen der Leistung gewählt, aber was es bedeutete, eine spezielle Tabelle für jede spezifische Produktkategorie (Blatt im Kategoriebaum) mit spezifischen Kategorieattributen (wie Auflösung für Fernsehgeräte) zu erstellen, die als separate Spalte modelliert wurden.
Während der Ausführung ist diese Konfiguration nicht flexibel, wenn Sie den vorhandenen Kategorien Attribute hinzufügen oder neue Kategorien hinzufügen müssen. Für jede solche Änderung wird folgendes benötigt:
Um mit dieser Komplexität fertig zu werden, denke ich, dass eine Art Meta-Darstellung dieser Attribute (auch außerhalb der Anwendung) in xml- oder sogar Excel-Dateien benötigt wird, so dass bei jeder Änderung der gesamte Code automatisch generiert werden kann. orm Abfragen, Anwendungscode, Vorlagen). So kann es bei der Entwicklung helfen, aber trotzdem sind Tests und zusätzliche Bereitstellung erforderlich.
An diesem Punkt habe ich gelernt, dass Ebay relational db für die Suche nicht wirklich verwendet und dass ihre Taxonomie so flexibel ist, dass sie ziemlich schnell neue Blattkategorien hinzufügen können. Auch sind ihre Kategorien wahrscheinlich keine Kategorien aus einem hierarchischen Baum, der in relationalen db modelliert wurde, sondern nur Suchattribute (Facetten).
Nach einem kurzen Blick in die vielversprechendste dedizierte facettierte Suche (separate Solr-Instanz) bin ich nicht sicher, ob es mir dabei helfen könnte, Taxonomieänderungen flexibel zu gestalten, da Solr normalerweise nur relationale DB spiegelt, also bestimmte Kategorieattribute müssen im DB noch als DBMS-Metadaten modelliert werden, also z. dynamisch generierende UI-Formulare zum Filtern von Attributen wären schwierig, es sei denn:
1) Ich würde die Daten in RDBMS mit EAV-Modus behalten und seine Leistungsprobleme mit der SOLR-Suche überwinden (aber es würde immer noch Probleme mit EAV-Unordnung geben, keine Datenintegritätserzwingung usw.)
2) Ich würde nur das Attributverzeichnis (dh nur deren Namen und Typen) in RDBMS behalten und die spezifischen Attributwerte in SOLR speichern, indem ich es als eine Art nicht-relationalen Datenspeicher neben der Suchfunktion verwende. Ich bin auch von dieser Lösung nicht überzeugt (auch wenn es möglich ist), da die Anwendung mit solr eng gekoppelt wäre (dh, die Produktausgabe-Admin CRUD würde direkt mit SOLR interagieren).
Was sind deine Gedanken? Denken Sie, dass für jede Art von solcher (performanter) Taxonomie die Generierung von Flexibilitätscode unumgänglich ist? Wie würdest du damit umgehen? Vielleicht ein separates Datenwörterbuch in EAV-Mode in DB nur für die Code-Generierung? Ich denke, ich könnte auch etwas wie MongoDB verwenden, aber die UI-Code-Generierung (Laufzeit oder nicht) würde immer noch eine Art von Metadaten benötigen.
Es gibt viele Fragen hier, aber ich wollte es nicht in kleinere Fragen aufteilen, da ich an einem allgemeinen Designansatz interessiert bin, wenn es um eine größere Klasse solcher Probleme geht.
Ich behaupte nicht, eine definitive Antwort auf all das zu haben (es ist eine ziemlich offene Frage, die Sie versuchen sollten, in kleinere Teile zu brechen, und es hängt von Ihren tatsächlichen Anforderungen ab, in der Tat bin ich versucht zu wählen um es zu schließen), aber ich werde ein paar Dinge kommentieren:
Was wäre, wenn Sie verschiedene Arten von Kategorien für verschiedene Arten von Produkten hätten?
Wenn wir das eBay-Beispiel verwenden, haben wir Produkte , die entweder Bücher oder TV / Displays sein können.
Bücher haben Titel und ISBN und können in der Kategorie sci-fi oder in der Kategorie erotisch oder in der Kategorie non-fiction oder autobiografisch sein. Oder vielleicht hast du ein Buch, das in den non-fiktiven, autobiographischen erotischen Kategorien steht.
Displays haben Bildschirmauflösung und Wattverbrauch (?) und können in der Kategorie Flachbildschirm, CRT oder HD sein.
Aus rein relationaler Sicht könnte man vielleicht das so modellieren:
%Vor% Anstatt attributes dependent on a particular product category zu modellieren, hätten Sie abhängig von type / class des Produkts andere Eigenschaften und Kategorien .
Tags und Links database-design solr nosql faceted-search