Wie man Mängel in der Berichterstattung von EAV-Datenbank zu überwinden?

Question

Die Hauptmängel bei Entity-Attribute-Value-Datenbankentwürfen in SQL scheinen alle damit verbunden zu sein, die Daten effizient und schnell abfragen und melden zu können. Die meisten Informationen, die ich zu diesem Thema gelesen habe, warnen vor der Implementierung von EAV aufgrund dieser Probleme und der Gemeinsamkeit von Abfragen/Berichten für fast alle Anwendungen.

Ich entwerfe gerade ein System, bei dem die Felder für eine der Entitäten zur Design-/Kompilierzeit nicht bekannt sind und vom Endbenutzer des Systems definiert werden. EAV scheint für diese Anforderung gut geeignet zu sein, aber aufgrund der Probleme, über die ich gelesen habe, zögere ich bei der Implementierung, da auch für dieses System einige ziemlich umfangreiche Berichtsanforderungen bestehen. I denke, Ich habe einen Weg gefunden, um diese Frage, aber möchte die SO-Community stellen.

Da die typische normalisierte Datenbank (OLTP) immer noch nicht die beste Option zum Ausführen von Berichten ist, scheint eine "Reporting" -Datenbank (OLAP), in die die Daten aus der normalisierten Datenbank kopiert werden, ausführlich indexiert und möglicherweise für eine einfachere Abfrage denormalisiert. Könnte die gleiche Idee verwendet werden, um die Mängel eines EAV-Designs zu umgehen? Der Hauptnachteil, den ich sehe, ist die erhöhte Komplexität der Übertragung der Daten von der EAV-Datenbank zum Reporting, da Sie am Ende die Tabellen in der Berichtsdatenbank ändern müssen, wenn neue Felder in der EAV-Datenbank definiert werden. Aber das ist kaum unmöglich und scheint ein akzeptabler Kompromiss für die erhöhte Flexibilität zu sein, die das EAV-Design bietet. Dieser Nachteil besteht auch, wenn ich einen Nicht-SQL-Datenspeicher (z. B. CouchDB oder Ähnliches) für den Hauptdatenspeicher verwende, da alle Standardberichterstellungstools erwarten, dass ein SQL-Backend abfragt.

Sind die Probleme mit EAV-Systemen meist weg, wenn Sie eine separate Berichtsdatenbank für die Abfrage haben?

EDIT: Danke für die Kommentare so weit. Eines der wichtigen Dinge an dem System, an dem ich gerade arbeite, ist, dass ich wirklich nur davon spreche, EAV für eine der Entitäten zu verwenden, nicht für alles im System.

Der Kern des Systems besteht darin, Daten aus verschiedenen Quellen, die nicht vorher bekannt sind, zu extrahieren und die Daten zu knacken, um einige "bekannteste" Daten über eine bestimmte Entität zu erhalten. Also ist jedes "Feld", mit dem ich es zu tun habe, mehrwertig und ich muss auch die Geschichte für jeden verfolgen. Der normalisierte Entwurf für diese endet, 1 Tabelle pro Feld zu sein, das die Frage irgendwie irgendwie schmerzhaft macht.

Hier sind die Tabellenschemata und Beispieldaten Ich betrachte (offensichtlich geändert, was ich arbeite, aber ich denke, es ist der Punkt gut illustriert):

EAV Tabellen

Person 
------------------- 
- Id - Name  - 
------------------- 
- 123 - Joe Smith - 
------------------- 

Person_Value 
------------------------------------------------------------------- 
- PersonId - Source - Field  - Value   - EffectiveDate - 
------------------------------------------------------------------- 
-  123 - CIA - HomeAddress - 123 Cherry Ln - 2010-03-26 - 
-  123 - DMV - HomeAddress - 561 Stoney Rd - 2010-02-15 - 
-  123 - FBI - HomeAddress - 676 Lancas Dr - 2010-03-01 - 
------------------------------------------------------------------- 

Berichtstabelle

Person_Denormalized 
---------------------------------------------------------------------------------------- 
- Id - Name  - HomeAddress - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
---------------------------------------------------------------------------------------- 
- 123 - Joe Smith - 123 Cherry Ln -     0.713 -    2010-03-26 - 
---------------------------------------------------------------------------------------- 

Normalisierten Entwurf

Person 
------------------- 
- Id - Name  - 
------------------- 
- 123 - Joe Smith - 
------------------- 

Person_HomeAddress 
------------------------------------------------------ 
- PersonId - Source - Value   - Effective Date - 
------------------------------------------------------ 
-  123 - CIA - 123 Cherry Ln -  2010-03-26 - 
-  123 - DMV - 561 Stoney Rd -  2010-02-15 - 
-  123 - FBI - 676 Lancas Dr -  2010-03-01 - 
------------------------------------------------------ 

Das „Confidence“ Feld hier erzeugt wird, unter Verwendung von Logik, die nicht so leicht ausgedrückt werden kann (wenn überhaupt) neue Werte SQL so meine häufigste Operation unter Verwendung neben Einfügen werden alle Daten über eine Person Strang ziehen für alle Felder, damit ich den Datensatz für die Berichtstabelle generieren kann.Das ist eigentlich einfacher im EAV-Modell, da ich eine einzige Abfrage ausführen kann. Im normalisierten Design muss ich schließlich 1 Abfrage pro Feld durchführen, um zu vermeiden, dass ein riesiges kartesisches Produkt alle zusammenfügt.

Answer 1

Kurze Antwort - ja, eine Reporting-Datenbank ist ein vernünftiger Ansatz zur Lösung der Probleme der Berichterstattung von einem EAV Datenmodell.

verbrachte ich einige Jahre mit einer Informations-Management-Lösung arbeiten, die Endanwendern völlige Freiheit erlaubt, ihr eigenes Datenmodell zu definieren, sowohl mit dem Schema und der ein EAV-Modell unter Verwendung der gespeicherten Daten. Interessanterweise lieferte dieses Produkt Metaschema-Objekte, die zur Erfüllung der Berichtspflichten verwendet wurden (z. B. Graphen zur Bereitstellung von Objektnavigation, Ansichten zur Durchführung von Projektionen usw.). Dies bedeutete, dass der Endbenutzer die Möglichkeit hatte, Abfragen unter Verwendung der gleichen Begriffe und Konzepte zu definieren, mit denen er das Datenmodell in der ersten Instanz erstellt hatte. Der Akt des Berichtswesens bestand im Wesentlichen darin, den Datensatz durch Navigieren durch diese Definitionen zu berechnen und das Ergebnis an ein herkömmliches Berichtsschreibtool zu übergeben, als ob es sich um relationale Daten handeln würde.

Eine der Stärken dieses Ansatzes war, dass derselbe Mechanismus, der bereits vorhanden war, um das EAV-Modell in etwas umzuwandeln, mit dem der Benutzer arbeiten konnte, wiederverwendet und auf die Berichtsfunktion angewendet werden konnte.

Answer 2

Das Problem mit EAV ist nicht auf EAV als solches zurückzuführen. Das liegt am Entwerfen und Erstellen einer Datenbank, ohne zu verstehen, was die Datenanforderungen wirklich sind und welche logische Struktur die Daten haben müssen, um diese Anforderungen zu erfüllen. EAV und jedes andere System, das den Benutzern erlaubt, ihre eigenen Daten zu entwerfen, stellt dies auf den Kopf.

In diesem Schema haben wir zuerst ein System entwickelt, mit dem Benutzer jede Art von Daten speichern können, unabhängig von ihrer Struktur und unabhängig von der künftigen Verwendung. Dann, wenn es an der Zeit ist, die Berichte zu veröffentlichen, müssen wir herausfinden, was wir haben und wie das mit dem zusammenhängt, was wir brauchen.

Viel Glück damit.

Answer 3

In diesem Schema haben wir zuerst ein System entwickelt, mit dem Benutzer jegliche Art von Daten speichern können, unabhängig von ihrer Struktur und unabhängig von der zukünftigen Verwendung. Dann, wenn es an der Zeit ist, die Berichte zu veröffentlichen, müssen wir herausfinden, was wir haben und wie das mit dem zusammenhängt, was wir brauchen.

Da Sie deutlich die Art des Problems Attribut „in diesem Schema zu sein“, so scheint es mir wirklich, als ob das Problem mit EAV wirklich ist durch als solche EAV.

In der Tat, um darüber nachzudenken: "Ein System, mit dem Benutzer jede Art von Daten speichern können" entspricht einem System, mit dem Benutzer nur ihre relvars definieren können. Aber welcher Teil des Systems erlaubt es den Benutzern, Einschränkungen für jedes Attribut zu definieren? Hoppla, die EAV-Crowd scheint einen nicht so unwichtigen Aspekt des Datenmanagements verpasst zu haben, es scheint ...

Answer 4

Es gibt kein Problem mit EAV Ich verbringe ziemlich viel Zeit mit der Abfrage von MASSIVE EAV-Datenbanken. Jeder, der sagt, dass das Berichten von EAV schwierig oder unmöglich ist, hat 1 von 2 Problemen, entweder haben sie ein sehr schlecht entworfenes EAV-System oder sie verstehen nicht, wie man von einem abfragt. Daten von einer EAV-Datenbank zu bekommen, ist ziemlich einfach, nachdem Sie es ein paar Mal gemacht haben. Es gibt keine Notwendigkeit für eine Berichtsdatenbank oder etwas Besonderes, nur ein paar gute Fragen.

Wenn Sie eine EAV DB viel Zeit für das Entwerfen erstellen, wird das Design entweder Ihre Anwendung machen oder brechen, und es wird ein Alptraum sein, der versucht, mit einem schlecht entworfenen zu beheben.