Sql Server Data Tools & Entity Framework - czy jest tu synergia?

Wychodząc z projektu wykorzystującego Linq2Sql, podejrzewam, że następny (większy) może popchnąć mnie w ramę Entity Framework. Przeczytałem trochę na ten temat, ale nie udało mi się znaleźć spójnej historii o tym, jak Narzędzia danych SQL Server i Entity Framework powinny / mogłyby / mogą być używane razem.

• Czy zostały poczęte całkowicie osobno, a używanie ich razem to głaskanie w niewłaściwy sposób?
• Czy są w jakiś sposób całkowicie ortogonalne i nie rozumiem tego?

Niektóre powody, dla których myślę, że mogę chcieć obu:

• SSDT doskonale nadaje się do „skompilowania” (zaznaczenia) i łatwej do aktualizacji wersji SQL i schematu
• Ale historia migracji / aktualizacji SSDT nie jest przekonująca (dla mnie): „Aktualizuj wszystko” działa dobrze dla schematu, ale nie ma możliwości (AFAIK), aby kiedykolwiek mógł działać dla danych.
• Z drugiej strony, nie próbowałem migracji EF, aby wiedzieć, czy stwarza podobne problemy, ale bity Up / Down wyglądają całkiem przydatne.

Pozwól mi przedstawić inny punkt widzenia. Utrzymanie bazy danych Entity Framework jest całkowicie bezużyteczne w każdym przedsiębiorczym lub dużym projekcie bazy danych.

Problemy to:

• Automatyczne aktualizacje schematu. To absolutnie nie to, czego chcę, ponieważ całkowicie narusza podstawy utrzymania bazy danych. Problemy są następujące: (a) ktoś z nowszą wersją aktualizuje bazę danych zamiast uzyskać problem i (b) aktualizacje są planowane, a dba zwykle wykonuje kopię zapasową PIERWSZĄ. Automatyczne aktualizacje są więc bezużyteczne.

• Tworzenie Db działa tylko na zasadniczo zdegenerowanych przypadkach krawędzi. Nawet nie próbuj używać zaawansowanych funkcji bazy danych - niezależnie od tego, która z nich. Przykład serwera SQL: pola uwzględnione w indeksach, filtry indeksów, partycjonowanie, kompresja, reguły sprawdzania poprawności pól.

• Migracja - ponownie zakłada przypadki zdegenerowania krawędzi: bez łatwej transformacji danych lub wieloetapowej aktualizacji. Przykład: Tabela X ma historyczne pole „użytkownik”, które rejestruje, że użytkownik coś robi. Nowa konfiguracja ma tabelę użytkowników, więc należy utworzyć tabelę użytkowników, a następnie utworzyć użytkowników, a następnie utworzyć pole referencyjne użytkownika w tabeli x, a następnie zaktualizować to przy użyciu użytkownika z tabeli użytkowników, a następnie usunąć pole użytkownika.

Jedynym rozsądnym sposobem radzenia sobie z tymi scenariuszami są skrypty generowania i migracji oraz odpowiednie wersjonowanie.

Teraz SSDT - to świetne narzędzie do wersjonowania konkretnej wersji bazy danych znacznie lepiej niż Entity Framework, ponieważ faktycznie - działa. Jak w: rejestruje wszystkie funkcje. W żadnej z baz danych, które mam, prawie mógłbym najpierw użyć kodu - ponieważ zawsze filtrowaliśmy przynajmniej indeksy;) EF nawet nie doprowadziłby mnie do 10% tego, czego potrzebuję.

Nasze podejście to:

• Zaprojektuj bazę danych w bazie danych, a następnie zsynchronizuj z modułem SSDT, który zostanie zalogowany. Synchronizacja schematu umożliwia programistom szybką aktualizację ich wersji. Zawsze istnieje gdzieś autorytatywna główna baza danych z bieżącą wersją (na specjalnym serwerze), więc mamy wersję referencyjną, z którą możemy pracować.

• Generuj skrypty delta zgodnie z potrzebami dla wydań, które również są wersjonowane i mają fajny mechanizm wdrażania ich w bazie danych.

Istnieje więcej niż jeden sposób użycia EF z bazą danych SQL Server.

1. Najpierw kod ... Piszesz klasy, a EF generuje powiązane tabele
2. Najpierw baza danych ... Projektujesz tabele, a EF generuje klasy.

EF niekoniecznie wykona za ciebie całą pracę. EF zapewni ci około 80 do 95 procent. Pozostałe 5 do 20 procent wysiłków związanych z tworzeniem bazy danych zostanie uzupełnione o takie optymalizacje, jak widoki i procedury przechowywane.

Więc nie, nie są ortogonalne. Musisz jednak zdecydować, jaka będzie twoja ogólna strategia projektowania, a następnie polegać na narzędziach takich jak SSDT, które pomogą zoptymalizować te części, w których EF daje mniej niż idealne wyniki.