Entity Framework 4 - Umgang mit sehr großen (1000+ Tabellen) - Daten-Modelle?

Wir haben eine Datenbank mit über 1000+ Tabellen und würde gerne zu prüfen, mit EF4 für die data-access-layer, aber ich bin besorgt über die praktischen Gegebenheiten mit es für eine so große Daten-Modell. Ich habe gesehen, diese Frage und Lesen Sie über die vorgeschlagenen Lösungen hier und hier. Diese können funktionieren, aber die scheinen zu beziehen sich auf die erste version des Entity Framework (und komplexer sind, als ich möchte). Weiß jemand, ob diese Lösungen wurden verbessert in EF4? Oder haben Sie andere Vorschläge alle zusammen? Danke.

UPDATE: Nach einer Reihe von versuchen zu machen, EF arbeiten, habe ich beschlossen, Sie zu verlassen alle gemeinsam für dieses Projekt. Große Daten-Modell-Unterstützung gibt es nicht und kann es werden Problemumgehungen Arbeit (z.B. Bearbeitung und Pflege der xml-unabhängig von der designer), die Sie gerade nicht das Gefühl, bereit für die prime time. Am problematischsten ist für mich die Tatsache, dass die EF funktioniert nicht gut mit dem domain-Modell erstrecken sich über mehrere XML-Dateien ohne viel Redundanz und Duplizierung von code. Ich bin immer noch offen für Verbesserungsvorschläge (ich weiß, ich habe Sie nicht geschält zurück alle Schichten der EF Zwiebel), aber für jetzt, ich bewege mich auf, ohne EF.

UPDATE #2: Es sieht aus wie die angemeldete erste code-Unterstützung (derzeit in EF4 CTP4) ist wahrscheinlich am Ende wird die Lösung, die wir wollen, wie es dauert, die designer und großen XML-Datei der Wartung aus dem Spiel.

  • Klingt verrückt... 1000+ Tabellen wäre nicht zugeordnet werden.. Sie sind Art von add, eine überwältigende monolithische Daten-access-Architektur. Es gibt etwas falsch mit der vorgeschlagenen Lösung. Freut mich zu Lesen, dass Sie hatte es aufgegeben.
  • Annahme von marc_s Antwort unten. Wie schon gesagt, ich denke, dass EF 4.1 ist der Weg zu gehen, nehmen die designer / XML-Wartung komplett aus dem Spiel. Wenn gezwungen, EF 4.0, dann denke ich, man ist eingeschränkt, denn er schreibt in seiner Antwort.
InformationsquelleAutor David Kreps | 2010-06-05
  1. 18

    Die Zahl, die ich hörte, in einer Microsoft screencast ist ein maximum von etwa 250 Tabellen pro EF-Modell. Das bedeutet nicht, dass EF nicht umgehen kann mehr - es kann nur sinnvoll sein, brechen Ihre 1000+ Tabellen in mehrere logische Gruppen von Tabellen und verwenden Sie ein EF-Modell pro solche logischen Gruppe (mit bis zu 250 Tabellen).

    Ich stark bezweifle, musst du Abfragen, müssen alle 1000 Tischen gleichzeitig - wahrscheinlich auch nicht 10 auf einmal. So sollten Sie auf jeden Fall in der Lage sein, um aufgeteilt Ihren ziemlich großes Modell in kleinere Cluster und drehen Sie jede in einem separaten EF-Modell.

    • Das ist ein Mist
    • Ich sehe nicht, warum Menschen ein problem mit diesem. Ich mache es im moment, und es macht Sinn. Ich habe eine DB mit über 300 Tabellen, aber ich bin der Aufteilung in 12 Modelle, da gibt es 12 "Gebiete" des Systems. Es ist wartbar und einfach. Was also, wenn code wird dupliziert...ich habe nicht schreiben den code!
    • da könnten Sie haben code geschrieben, der hat Sachen zu einigen Personen und nicht möchten, dass code dupliziert werden jedes mal, wenn diese Entität wird in einem "Bereich"
    • Wir haben mit EF seit beta 2 und sind jetzt auf dem aktuellen Stand zu EF5. Wir haben über 500 Tischen in unserem wichtigsten Modell mit mehreren anderen Modellen in verschiedenen Größen. VS funktioniert einwandfrei, es gibt keine harte Beschränkung. In VS2008 war es mehr Speicher-Beschränkung. Mit jeder neuen Version von EF, Unterstützung bei großen Modellen wurde verbessert. Das größte problem ist nicht, dass VS nicht verarbeiten kann es jetzt, aber nur die Verwaltung, die Menge von Entitäten.
    InformationsquelleAutor marc_s
  2. 7

    Sollten Sie auf jeden Fall werfen Sie einen Blick auf LLBLGen Pro v3. Während LLBLGen ist ein weiterer O/RM-tool, genau wie EF ist eine O/RM-tool, die neueste version enthält einen designer, der Ihnen erlaubt, um Modelle zu generieren, die für LINQ to SQL, NHibernate UND Entity Framework (sowohl 1.0 und 4.0). Seine designer ist ziemlich solide und hat eine bessere Unterstützung für große domain-Modelle.

    • Das Klang wie eine ziemlich gute Lösung, aber LLBLGenPro wurde nicht mehr reagiert, sobald ich versuchte, Sie zu öffnen, eine Verbindung zu meiner Datenbank. Offenbar läuft die Anwendung eine eher ineffiziente Abfrage gegen die INFORMATION_SCHEMA-Ansichten zu erstellen, die Objekt-Katalog. Könnte ich wahrscheinlich umgehen, indem man den timeout-Wert größer als 10 Minuten für die Datenbank-Verbindung, sondern zu warten, für 10 Minuten jedes mal, wenn ich ändern möchten, das Modell fühlt sich nicht wie eine sehr brauchbare Lösung. Danke für den Vorschlag, aber!
    • Ich rate Ihnen, sich mit dem Schöpfer durch E-mail-forum. Sie haben sehr reaktionsschnellen support. Ich Wette, Sie können sagen, Sie sehr schnell, was Sie falsch machen. Und wenn es ein Fehler ist, Sie haben in der Regel einen fix in kürzester Zeit. Viel Glück.
    • Sind Sie sicher, dass Sie nicht haben, eine wirklich langsame Verbindung? 1000 Tabellen, gar nicht so groß - wir haben um die viele und LLBL zieht die Objekt-Dateien UND generiert alle die ORM-code in unter 5 Minuten. Wir sind auch gerade mit geraden LLBL, anstatt es zu generieren, EF4 oder anderen ORM-code.
    • Ich schrieb LLBLGen Pro und habe es getestet auf einer db mit über 1000 Tabellen, ohne Probleme. Die Abfrage über informationschema, ist, dass der FK-Abfrage ein? Wenn möglich, könnten Sie geben mehr Informationen durch posten von einem Beitrag in unserem Forum oder mailen Sie uns an support BEI llblgen DOT com? Danke!
    • Ja, es war auf jeden Fall die FK-Abfrage. Ich habe eine E-Mail geschickt mit mehr detail pro Ihren Antrag. Danke!
    • Dank David Kreps wir das Problem entdeckt und geschrieben haben, eine neue FK meta-Daten-retrieval-query, die ist super schnell auf 2005/2008, und verfügbar sein wird im nächsten build (v3.0-builds, die nach september 17). 🙂 Also diese Langsamkeit auf mega-dichten Modelle mit einer Menge von Tabellen (1000+) ist nun gelöst 🙂

    InformationsquelleAutor Steven
  3. 2

    Ich bin mir sicher, dass nicht alle 1000+ Tabellen verknüpft sind. Brechen Sie in logische Teile.

    InformationsquelleAutor Dustin Davis
Schreibe einen Kommentar