Alternativen zu Entity-Attribut-Value (EAV)?

Question

Unsere Datenbank basiert auf dem EAV-Modell (Entity-Attribute-Value). Diejenigen, die mit EAV-Modellen gearbeitet haben, kennen den ganzen Mist, der mit dem Ziel der Flexibilität einhergeht.

Ich fragte meinen Kunden nach den Gründen, warum EAV-Modell (Flexibilität) verwenden, und ihre Antwort war: Ihre Entitäten ändern sich im Laufe der Zeit. Daher können sie heute eine Tabelle mit ein paar Attributen haben, aber in einem Monat können einige neue Attribute hinzugefügt werden, oder ein vorhandenes Attribut kann umbenannt werden. Sie müssen Berichte erstellen, um zu jedem Zeitpunkt zurückzukehren und die Daten basierend auf der Form der Entitäten in diesem Stadium abzufragen.

Ich verstehe, dass dies mit einem herkömmlichen relationalen Modell nicht machbar ist, aber ich persönlich sehe EAV als Anti-Pattern. Gibt es weitere alternative Modelle, die es uns ermöglichen, die zeitliche Dimension in Änderungen an den Entitäten und Instanzen zu erfassen?

Cheers, Mosh

Answer 1

Erstellen Sie eine neue Tabelle Beschreibung für jede Version Beschreibung Entity und eine zusätzliche Tabelle, die Sie ist die Tabelle zeigt, welche Version. Das Abfragesystem sollte ebenfalls aktualisiert werden.

Ich denke, Erstellen eines Skripts, das generiert, Tabellen und Abfragen ist Ihre beste Einstellung.

Answer 2

Unabhängig von der Art des verwendeten relationalen Modells erfordert die Verfolgung von Feldnamenänderungen eine Menge Metadaten, die Sie in Transaktionsprotokollen oder Audit-Tabellen verfolgen müssen. Leider ist die Abfrage eines dieser Zustände zu einem bestimmten Zeitpunkt sehr kompliziert. Wenn Ihr Client den Status nur zu einem bestimmten Zeitpunkt benötigt, also den gesamten Status, nicht nur in Bezug auf Namensänderungen, können Sie die Datenbank duplizieren und das Transaktionslog auf die benötigte Zeit zurücksetzen und Ihre Abfragen für die neue Instanz ausführen . Wenn Entitäten, die nach dem angegebenen Datum hinzugefügt wurden, jedoch in der Abfrage mit den alten Feldnamen angezeigt werden müssen, liegt ein sehr großes Entwicklungsproblem vor Ihnen. In diesem Fall würde ich mit den Informationen, die Sie in Ihrer Frage angegeben haben, vorschlagen, Alternativen mit dem Kunden auszuhandeln oder mehr Informationen über die Verwendung der Berichte zu erhalten, um alternative Lösungen zu finden.

Sie könnten zu einem dokumentbasierten Datenspeicher wechseln, aber das würde das Problem im zweiten Fall immer noch nicht lösen. Entschuldigung, das ist nicht wirklich eine Antwort, aber nachdem wir ähnliche Situationen durchgespielt haben, braucht der Kunde wahrscheinlich eine realistischere Berichtslösung oder eine Anzahl anderer Investoren, die bereit sind, die Hauptstadt für das Engineering vorzurücken.

Als dieses Problem für uns aufkam, haben wir das Schema db konstant gehalten und eine Entity-Mapping-Factory basierend auf einem Zeitstempel implementiert. Am Ende änderte der Kunde kontinuierlich die Anforderungen (wöchentlich oder monatlich), wie aggregierte Felder berechnet wurden und nie vollständig erfüllt wurden.

Answer 3

Es gibt einen Unterschied zwischen EAV, der treu oder schlecht gemacht wird; 5NF von erfahrenen Leuten oder von denen, die keine Ahnung haben.

Sechste Normalform ist die nicht reduzierbare Normalform (keine weitere Normalisierung ist möglich). Es beseitigt viele der Probleme, die häufig auftreten, z. B. das Nullproblem, und bietet die ultimative Methode zum Identifizieren fehlender Werte. Es ist die wissenschaftlich und technisch robuste NF. Es gibt keine Produkte, die dies unterstützen, und es wird nicht häufig verwendet. Um korrekt und konsistent implementiert zu werden, muss ein Katalog für Metadaten implementiert werden. Natürlich wird das SQL, das für die Navigation benötigt wird, noch umständlicher (SQL ist bereits mühselig), aber dies lässt sich leicht umgehen, indem die Produktion von SQL aus den Metadaten automatisiert wird.

EAV ist ein Teilsatz oder eine Teilmenge von 6NF. Das Problem besteht in der Regel in einem bestimmten Zweck (damit Spalten hinzugefügt werden können, ohne DDL-Änderungen vornehmen zu müssen) und in Personen, die die 6NF nicht kennen und keine Metadaten implementieren. Der Punkt ist, 6NF und EAV als Prinzipien und Konzepte bieten erhebliche Vorteile, und die Leistung steigt; aber normalerweise wird es nicht richtig implementiert, und die Vorteile werden nicht realisiert. Einige EAV-Implementierungen sind Katastrophen, nicht weil EAV schlecht ist, sondern weil die Implementierung schlecht ist.

Eg. Einige Leute denken, dass das SQL, das benötigt wird, um die 3NF-Zeilen aus der 6NF/EAV-Datenbank zu konstruieren, komplex ist: Nein, es ist umständlich, aber nicht komplex. Noch wichtiger ist, dass eine gewöhnliche SQL VIEW bereitgestellt werden kann, so dass alle Benutzer und Berichttools nur die direkte 3NF VIEW sehen und die 6NF/EAV Probleme für sie transparent sind. Zuletzt kann das benötigte SQL automatisiert werden, so dass die Arbeitskosten, die viele Menschen ertragen müssen, nicht notwendig sind.

So ist die Antwort wirklich, Sixth Normal Form, der Vater von EAV, und eine reinere Form, ist der Ersatz dafür. Der Vorbehalt ist, stellen Sie sicher, dass es richtig gemacht wird. Ich habe eine große 6NF db, und es leidet keine der Probleme, über die Leute Post, es funktioniert sehr gut, der Kunde ist sehr glücklich (keine weitere Arbeit ist ein Zeichen der vollständigen Funktionszufriedenheit).

Ich habe gepostet bereits eine sehr ausführliche Antwort auf eine andere Frage, die auch auf Ihre Frage gilt, die Sie interessieren könnten.

Other EAV Question

Answer 4

auf die Antworten von @NickLarsen und @PerformanceDBA hinzufügen

Wenn Sie historische Änderungen zu Dingen wie Feldname verfolgen müssen, möchten Sie vielleicht in etwas wie Slowly Changing Dimensions suchen. Es scheint mir, als ob Sie die EAV verwenden, um dynamische dimensionale Modelle zu modellieren (wahrscheinlich Lookup-Listen). Die einfachste (und wahrscheinlich am wenigsten effiziente) Art, dies zu erreichen, wäre, ein "Wie-vom-Datum" -Feld in EAV-Tabellen einzufügen, und wenn eine Änderung auftritt, fügen Sie einen neuen Datensatz (anstatt einen vorhandenen Datensatz zu aktualisieren) mit ein das aktuelle Datum Das bedeutet, dass Sie Ihre Abfragen so ändern müssen, dass sie immer ein "ab" -Datum enthalten oder nach "jetzt" suchen, oder "jetzt" angeben, wenn keines bereitgestellt wird. Ihre Basis-Entität, die sich mit den EAV-Objekten verbindet, müsste dann "Top 1" aus der EAV-Tabelle abfragen, wobei "ab Datum" kleiner oder gleich dem Datum "letzte Aktualisierung" der Zeile ist, sortiert nach "ab" absteigend. Worst-Case-Szenario: Wenn Sie die letzte Änderung an einer gegebenen Zeile verfolgen müssen, in der sich sowohl der Name (in der Tabelle 'attribute' gespeichert) als auch der Wert geändert haben, würden Sie diese Logik mit der 'zuletzt geändert' der Reihe, um den passenden Wert für dieses bestimmte Datum zu finden.

Dies hat natürlich das Potenzial, große Datenmengen zu generieren, wenn es viele Änderungen gibt. Deshalb wird dieser Ansatz als "langsam" bezeichnet. Es ist für dimensionale Werte gedacht, die sich ändern können, aber nicht sehr oft. Um die Abfrageleistung zu unterstützen, sollten Indizes für die Felder "ab" und "zuletzt geändert" hilfreich sein.