SQL Server Data Tools & Entity Framework - Gibt es hier Synergien?

Wenn ich aus einem Projekt mit Linq2Sql herauskomme, vermute ich, dass das nächste (größere) mich in die Arme von Entity Framework drängen könnte. Ich habe einige Informationen zu diesem Thema gelesen, aber was ich nicht gefunden habe, ist eine zusammenhängende Geschichte darüber, wie SQL Server-Datentools und Entity Framework zusammen verwendet werden sollten / könnten / könnten.

• Wurden sie völlig getrennt konzipiert, und wenn man sie zusammen verwendet, streichelt man den falschen Weg?
• Sind sie irgendwie total orthogonal und ich verpasse den Punkt?

Einige Gründe, warum ich denke, ich möchte vielleicht beides:

• SSDT eignet sich hervorragend für die Kompilierung (Überprüfung) und die einfache Versionierung von SQL und Schema
• Aber die SSDT-Geschichte 'Migration / Update' überzeugt (für mich) nicht: "Alles aktualisieren" funktioniert für das Schema in Ordnung, aber es gibt keine Möglichkeit (AFAIK), dass es jemals für Daten funktionieren kann.
• Andererseits habe ich die EF-Migration nicht ausprobiert, um festzustellen, ob sie ähnliche Probleme aufweist, aber die Up / Down-Bits sehen recht praktisch aus.

Lassen Sie mich einen anderen Standpunkt vertreten. Die Wartung der Entity Framework-Datenbank ist in jedem Unternehmen oder großen Datenbankprojekt völlig nutzlos.

Probleme sind:

• Automatische Schemaaktualisierungen. Dies ist absolut nicht das, was ich will, da es die Grundlagen der Datenbankpflege völlig verletzt. Probleme sind: (a) jemand, der eine neuere Version ausführt, aktualisiert die Datenbank, anstatt ein Problem zu bekommen, und (b) Updates werden so geplant, dass die Datenbank normalerweise zuerst eine Sicherung durchführt. Automatische Updates sind also nutzlos.

• Die Datenbankerstellung funktioniert nur bei grundsätzlich entarteten Randfällen. Versuchen Sie nicht einmal, erweiterte Datenbankfunktionen zu verwenden - unabhängig davon, welche. SQL Server-Beispiel: Eingeschlossene Felder in Indizes, Filter für Indizes, Partitionierung, Komprimierung, Validierungsregeln für Felder.

• Migration - geht wieder von entarteten Randfällen aus: Keine Datentransformation oder mehrstufige Aktualisierung einfach. Beispiel: Tabelle X enthält ein historisches "Benutzer" -Feld, in dem aufgezeichnet wird, dass der Benutzer etwas tut. Das neue Setup verfügt über eine Benutzertabelle. Sie müssen also die Benutzertabelle erstellen, dann die Benutzer erstellen, dann das Benutzerreferenzfeld in Tabelle x erstellen, diese mit dem Benutzer aktualisieren, der aus der Benutzertabelle stammt, und dann das Benutzerfeld löschen.

Der einzig sinnvolle Weg, um mit diesen Szenarien umzugehen, sind Generierungs- und Migrationsskripte und eine ordnungsgemäße Versionierung.

Nun, SSDT - das ist ein großartiges Tool, um eine bestimmte Datenbankversion viel besser als Entity Framework zu versionieren, weil es tatsächlich funktioniert. Wie in: Es zeichnet alle Funktionen auf. In keiner meiner Datenbanken könnte ich so ziemlich zuerst Code verwenden - weil wir immer mindestens Indizes gefiltert haben;) EF würde mich nicht einmal auf 10% von dem bringen, was ich brauche.

Unser Ansatz ist:

• Entwerfen Sie die Datenbank in der Datenbank und synchronisieren Sie sie anschließend mit einem SSDT-Modul, das eingecheckt wird. Mit der Schemasynchronisierung können Entwickler ihre Version schnell aktualisieren. Es gibt immer irgendwo eine autorisierende Master-Datenbank mit der aktuellen Version (auf einem speziellen Server), sodass wir eine Referenzversion haben, gegen die wir arbeiten können.

• Generieren Sie nach Bedarf Delta-Skripte für Releases, die ebenfalls versioniert werden, und verfügen über einen nützlichen Mechanismus, um sie in einer Datenbank bereitzustellen.

Es gibt mehrere Möglichkeiten, EF mit einer SQL Server-Datenbank zu verwenden.

1. Code-First ... Sie schreiben Klassen und EF generiert die zugehörigen Tabellen
2. Datenbank zuerst ... Sie entwerfen die Tabellen und EF generiert die Klassen.

EF erledigt nicht unbedingt die gesamte Arbeit für Sie. Mit EF erhalten Sie dort etwa 80 bis 95 Prozent. Die anderen 5 bis 20 Prozent Ihres Datenbankentwicklungsaufwands werden durch Optimierungen wie Ansichten und gespeicherte Prozeduren ergänzt.

Also nein, sie sind nicht orthogonal. Sie müssen jedoch entscheiden, wie Ihre allgemeine Entwurfsstrategie aussehen soll, und sich dann auf Tools wie SSDT verlassen, um die Teile zu optimieren, bei denen EF weniger als ideale Ergebnisse erzielt.