Beispiele für Entity Framework 4: Zuordnung von POCOs zur EAV-Datenbank?

8

Unser Kunde wirbt für Produkte, aber die Eigenschaften des Produkts sind sehr unterschiedlich. Es gibt fast so viele Produktklassen wie Produkte.

Ursprünglich haben wir eine EAV-Datenbank erstellt, in der wir Attribute für jede "Produktklasse" hinzugefügt und entfernt haben. Die ganze Sache funktioniert sehr gut, aber die Komplexität ist betäubt. Dies ist Datenbank # 1.

Wir haben uns schließlich eine Reihe von Feldern ausgedacht, die alle Produkte repräsentieren (POCOs) und die "extra" -Felder in ein XML-Feld "catch all" verschieben. Dies ist Datenbank # 2.

Jetzt haben wir einige Kunden, die alte und einige Kunden verwenden, die das neue verwenden werden. Wir wollten wirklich nicht das alte aktualisieren, bis wir es tun mussten, aber wir haben von Zeit zu Zeit Änderungen, die wegen der EAV-Struktur einfach länger dauern als nötig.

Fragen:

  1. Irgendwelche Beispiele dafür, wie EF so programmiert werden kann, dass POCOs in EAV-Datenbanken persistent sind (wo Sie eine Tabelle mit Feldnamen und eine Tabelle mit Daten haben)?
  2. Sollten wir die Datenbank einfach verschrotten und für all diese älteren Kunden "normale" Tabellen schreiben, wenn wir von Zeit zu Zeit Änderungen vornehmen?

Normal bezieht sich natürlich auf die normale Form von Boyce Codd.
Wir haben die ältere Datenbank bearbeitet, indem wir ihre Struktur in die Software ausgeleert und dann POCOs im Repository zugeordnet haben.

    
Zachary Scott 29.09.2010, 19:35
quelle

1 Antwort

10

EAV-Tabellen sind in der Regel ein schmutziges Geschäft, und Joe Celko (in Die EAV der Zerstörung vermeiden ) und viele andere Branchenexperten (zB Fünf einfache Datenbank-Design-Fehler, die Sie vermeiden sollten ) warnen zu Recht vor der Verwendung von EAV-Konstrukten zu viel.

Alle Datenbankkritiker beiseite: Wie würde ein Objekt in .NET, das auf solch einem EAV basiert, sogar aussehen ?? Es könnte eine beliebige Anzahl von Eigenschaften eines beliebigen Typs haben, also müsste es im Grunde ein "universelles" Objekt sein, das jede Form annehmen kann.

Dieser Gedanke lässt meine Haut krabbeln und widerspricht den grundlegendsten Konzepten einer stark typisierten Sprache - ja, man kann sowas in einer dynamischen Sprache wie Ruby und Python machen, aber in C #?

Die einzige praktikable Option, die Sie haben, könnte mit dem neuen "dynamischen" Typ in .NET 4.0 und dem ExpandoObject kommen - ein Objekt, das beliebige Formen annehmen kann, beliebige Eigenschaften von jedem Typ haben und im Grunde genommen beliebig sein kann Sein.

Sie können sich eine Zuordnung zwischen einer EAV-Struktur in SQL Server und einem ExpandoObject in C # 4.0 vorstellen - aber ich bezweifle sehr, dass das EF-Team in dieser Hinsicht etwas getan hat, und ehrlich gesagt glaube ich nicht, dass sie es bald tun werden . Aber dies könnte eine Möglichkeit für Sie sein, zu erkunden.

Für das ExpandoObject, siehe:

marc_s 29.09.2010, 20:46
quelle

Tags und Links