Hat jemand eine sehr große EAV oder offene Schema-Stil-Datenbank in SQL Server implementiert? Ich frage mich, ob es Leistungsprobleme gibt und wie Sie diese Hindernisse überwinden konnten.Leistung von großen EAV/offenen Schemasystemen auf SQL Server
Ich bin kein Experte für EAV, aber einige mehr erfahrene Entwickler als ich habe kommentiert, dass Magento Open-Source-E-Commerce-Framework langsam ist vor allem wegen der EAV-Architektur durch MySQL. Der offensichtlichste Nachteil kann nicht einfach überwunden werden. Dies ist die Schwierigkeit, mit der es zu beheben ist, wo und wie Informationen für Entitäten und Attributwerte dargestellt werden, wenn die Größe der Anwendung zunimmt. Das zweite Argument gegen EAV, das ich gehört habe, ist, dass es Tabellen-Joins benötigt, die tief zweistellig werden, aber es wurde angemerkt, dass die Verwendung von InnoDB über MyISAM die Performance etwas verbessert (oder umgekehrt), aber ich kann mich nicht vollständig erinnern).
Unabhängig von MS SQL Server im Vergleich zu anderen Marken der Datenbank, ist das schlimmste Leistungsproblem mit EAV, dass Menschen Monster-Abfragen versuchen, um eine Entität in einer einzigen Zeile zu rekonstruieren. Dies erfordert eine separate Verknüpfung pro Attribut.
SELECT e.id, a1.attr_value as "cost", a2.attr_value as "color",
a3.attr_value as "size", . . .
FROM entity e
LEFT OUTER JOIN attrib a1 ON (e.entity_id = a1.entity_id AND a1.attr_name = 'cost')
LEFT OUTER JOIN attrib a2 ON (e.entity_id = a2.entity_id AND a2.attr_name = 'color')
LEFT OUTER JOIN attrib a2 ON (e.entity_id = a3.entity_id AND a3.attr_name = 'size')
. . . additional joins for each attribute . . .
Egal, welche Datenbankmarke Sie verwenden, mehr Joins in einer Abfrage bedeutet geometrisch steigende Leistungskosten. Sie benötigen zwangsläufig genügend Attribute, um die Architekturkapazität einer beliebigen SQL-Engine zu übertreffen.
Die Lösung besteht darin, die Attribute in Zeilen anstelle von Spalten abzurufen und eine Klasse in den Anwendungscode zu schreiben, um diese Zeilen zu durchlaufen, wobei die Werte nacheinander den Objekteigenschaften zugewiesen werden.
SELECT e.id, a.attr_name, a.attr_value
FROM entity e JOIN attrib a USING (entity_id)
ORDER BY e.id;
Diese SQL-Abfrage ist so viel einfacher und effizienter, dass sie den zusätzlichen Anwendungscode ausgleicht. In einem EAV-Framework würde ich nach einem Standardcode suchen, der ein mehrzeiliges Ergebnisset wie folgt abruft und die Attribute den Objekteigenschaften zuordnet, und dann die Sammlung der aufgefüllten Objekte zurückgibt.