Datenbankdesign: Flexibilität vs. Einfachheit

Ich würde fast immer # 1 wählen - ich bevorzuge es, Attribute als Spalten in meinen Tabellen zu haben - macht Abfragen, Indizierung für die Performance und die allgemeine Handhabung viel einfacher und transparenter.

Die # 2 Option wird EAV - Entity Attribut Value genannt - und hat einige große Nachteile - siehe

• Fünf einfache Fehler beim Datenbankentwurf, die Sie vermeiden sollten - der EAV-Ansatz ist # 3 auf dieser Liste
• Joe Celko: Vermeidung der EAV der Zerstörung

Es ist interessant, dass Sie weder Leistung noch Datenintegrität als Bedenken erwähnen. Für was es wert ist, Modell # 1 ist der beste Ansatz für diese Überlegungen.

Flexibilität ist in Bezug auf Datenmodelle stark überbewertet. Die meisten Tabellenstrukturen sind zu Beginn der Entwicklung bekannt und bleiben während der gesamten Lebensdauer einer Datenbank stabil. Wenn Sie eine Anwendung haben, bei der das Modell wirklich flüssig und unerkennbar ist, sollten Sie wahrscheinlich überhaupt kein RDBMS verwenden. Wählen Sie stattdessen eines der NoSQL-Produkte.

Das ist also eine andere Wahl für # 1.

Jede Lösung hat ein Problem zu lösen. # 1 ist ein guter Ansatz, wenn Sie die Spalten kennen, die Sie im Voraus benötigen. In einigen Fällen sind die Spalten jedoch nicht im Voraus bekannt. Zum Beispiel benutzerdefinierte Felder, die ein Benutzer einer Funktionalität hinzufügt.

Having said that, EAVs haben eine Fülle von Problemen. Bei richtiger Verwendung sind IMO nützlich.

1. Stellen Sie sicher, dass Sie keine EAV für alles erstellen. Es ist nur für "unbekannte Gegenstände".
2. Denken Sie daran, dass EAVs keine Abhängigkeit von Fremdschlüsseln haben.
3. Die Leistung ist wegen nicht-trivialer Abfragen gering, und die Wartung kann mehr sein.
4. Bedenken Sie, dass die EAVs gedreht werden müssen, um sie sinnvoll zu machen (naja, meistens).

Option 1 fast immer. Option 2 ist sehr ineffizient. Es ist auch ziemlich tollpatschig, leicht nachzufragen, wenn man etwas effizienter machen muss. Nachdem ich das gesagt habe, habe ich eine Reihe von Produkten gesehen, die dies für benutzerdefinierte Attribute tun. Beispiele für Systeme, die das Option-2-Verfahren verwenden, sind Agresso und Kalido.

Wenn Sie eine maßgeschneiderte Anwendung erstellen, ist es bei weitem die beste Methode, Attribute hinzuzufügen, indem Sie das Datenbankschema einfach erweitern, wenn Sie es benötigen. Da die Änderung von Änderungen des Codes begleitet wird, kann dies als Teil des Freigabeprozesses durchgeführt werden.

Wenn Sie eine verpackte Anwendung ausführen, die Kunden selbst konfigurieren sollen, haben Sie drei Ansätze, die Sie verwenden können.

1. EAV-Struktur wie Option 2. Dies ist flexibel, aber ineffizient abzufragen, insbesondere da die Abfragen mit mehreren Joins komplex werden.

2. Machen Sie eine Reihe von Benutzerfeldern (User1, User2 usw.) für die Tabellen. Dies beschränkt Sie auf eine endliche Zahl, aber das kann ziemlich groß sein (Sie könnten User01-User99 haben, wenn Sie wollten). Es ist jedoch die effizienteste und einfachste Abfrage. Die andere Konsequenz ist, dass die Felder etwas undurchsichtig sind. Sie müssen Zugriff auf Konfigurationsinformationen haben, um die Bedeutung von "Benutzer3" zu kennen. Es opfert auch etwas Art Sicherheit. Unter dem Strich wird Ihr Benutzerfeld-Mechanismus jedoch einige seiner eigenen Metadaten und ein generisches Framework irgendeiner Art haben, so dass ein Teil dieses Typs Sicherheit dadurch bereitgestellt werden kann. Das sieht am unelegantesten aus Dies ist in den meisten Fällen der beste Weg, da es die beste Leistung und die einfachsten Abfragen bietet. Es ist mit Abstand das einfachste Schema, mit dem man arbeiten kann.

3. XML. Dies ist unendlich flexibel, aber die meisten Tools rund um die Datenbank arbeiten nur schlecht mit XML. Außerdem speichert es das XML in separaten Zuordnungseinheiten aus der Haupttabelle, sodass es zu erheblichen Problemen bei der Abfrageleistung kommen kann. XML-basierte Strategien sind sehr anwendungszentriert auf Kosten anderer Datenkonsumenten. Nach meiner Erfahrung wird die Speicherung signifikanter Datenmengen in XML-Feldern in einer Datenbank die TCO Ihrer Anwendung erheblich steigern. In den meisten Fällen nicht für Benutzerdatenfelder empfohlen.

@marc_s Ich glaube nicht, dass man "fast immer" eine Auswahl unter den oben genannten Optionen treffen kann. Es gibt einen Fall, um beide Lösungen zu unterstützen.

Option # 1 Gehen Sie dafür, wenn die Entität X gut definiert ist, d. H. Sie wissen genau, was Sie erfassen müssen, um X zu definieren. In einem solchen Fall erfasst ein einzelner Datensatz von X ziemlich genau alles, für das eine Instanz von X steht.

Option # 2 Gehen Sie dafür, wenn solch eine Entität X nicht vollständig definiert werden kann, d. H. Sie wissen nicht, welche Satzattribute erforderlich sind, um sie "vollständig" zu definieren.

Für z.B. Nehmen Sie ein Beispiel für einen Mitarbeiterdatensatz, wie im Artikel "Fünf einfache Datenbankentwurfsfehler, die Sie vermeiden sollten" erwähnt wird [Link von @marc_s]. Ja!!! Sie werden versucht sein, sich für Option 1 zu entscheiden, aber wenn Sie den Fall von Mitarbeitern in großen Organisationen betrachten, einmal die Mitarbeiterinformationen einzeln aufzeichnen - sowohl ihre Definition als auch ihr Inhalt ist sehr dynamisch und die Kombination von Option 1 und Option 2 erforderlich.

@marc_s

Obwohl ich das Beispiel der Mitarbeiterakte erwähnt habe, bin ich mir sicher, dass das nicht sehr überzeugend ist.

Hier ist das Beispiel aus der Finanzdomäne.

Wenn Sie alle Attribute eines Geschäfts erfassen möchten, hängt dies von seinem Instrumententyp ab. Es ist viel einfacher, die meisten Forex, Geldmarkt sogar Bond-Instrumente zu erfassen, da sie sehr strukturiert sind. Aber wenn wir uns auf derivative Produkte zubewegen, wird es sehr beschwerlich. Sie sind sehr exotisch in der Natur und ändern sich in Bezug auf die Struktur (daher ihre Bedeutung usw.). Um solche sich dynamisch verändernden Informationen zu erfassen, sollten wir uns für EAV entscheiden. Natürlich sollte man sich bei dieser Wahl bewusst sein, dass es viele negative Punkte in Ihrem Kommentar enthält.

Ich kann nicht über andere Bereiche sprechen, aber ich bin mir sicher, dass Sie feststellen werden, dass IT-Systeme in vielen Geschäftsbereichen mit dieser Situation konfrontiert sind und daher ein gutes Verständnis der EAV-Strategie - im Gegensatz zu ihrer direkten Ablehnung - haben wird Idee.

Shrini

Wie schon gesagt, hängt es von Ihren Anforderungen ab. Sie sollten # 2 nur dann wählen, wenn Sie zum Beispiel neue Attributtypen als Teil Ihres Programm-Workflows hinzufügen müssen. Das Hinzufügen neuer Spalten in Ihren Tabellen ist sicherlich schlimmer als eine zusätzliche Tabelle und eine zusätzliche Verknüpfung in Ihren Abfragen.