SQL Server Data Tools＆Entity Framework-ここに相乗効果はありますか？

Linq2Sqlを使用したプロジェクトから出てくると、次の（より大きな）ものがEntity Frameworkの腕に私を押し込むかもしれないと思います。私はこのテーマについてある程度調べましたが、見つけられなかったのは、SQL Server Data ToolsとEntity Frameworkをどのように使用する/使用する/使用するかについての一貫した話です。

• それらは完全に別々に構想されていたのですか？
• それらは何らかの形で完全に直交しているのですか？

両方が必要だと思う理由：

• SSDTは、「コンパイル済み」（チェック済み）で、バージョン管理が容易なSQLおよびスキーマを持つのに最適です
• しかし、SSDTの「移行/更新」の話は説得力がありません（私にとって）。「すべてを更新する」はスキーマでは問題なく動作しますが、データで動作する方法はありません（AFAIK）。
• 一方で、同様の問題が発生するかどうかを知るためにEFの移行を試みたことはありませんが、Up / Downビットは非常に便利に見えます。

別の観点から見てみましょう。Entity Frameworkデータベースのメンテナンスは、企業や大規模なデータベースプロジェクトではまったく役に立ちません。

問題は次のとおりです。

• 自動スキーマ更新。データベースのメンテナンスの基本に完全に違反しているので、これは私が望むものではありません。問題は次のとおりです。（a）新しいバージョンを実行している人が問題を取得する代わりにデータベースを更新し、（b）更新が通常最初にバックアップを取得するdbaでスケジュールされます。そのため、自動更新は役に立ちません。

• Dbの作成は、基本的に退化したエッジケースでのみ機能します。高度なデータベース機能を使用しようとしないでください-どの機能であっても。SQLサーバーの例：インデックスに含まれるフィールド、インデックスのフィルター、パーティション化、圧縮、フィールドの検証ルール。

• 移行-エッジケースが再び退化することを前提としています。データ変換やマルチステップ更新は簡単ではありません。例：表Xには、ユーザーが何らかの操作を行ったことを記録する履歴「ユーザー」フィールドがあります。新しいセットアップにはユーザーテーブルがあるため、ユーザーテーブルを作成してからユーザーを作成し、テーブルxにユーザー参照フィールドを作成してから、ユーザーテーブルからのユーザーでこれを更新し、ユーザーフィールドを削除する必要があります。

これらのシナリオに対処する唯一の賢明な方法は、生成および移行スクリプトと適切なバージョン管理です。

現在、SSDTは、Entity Frameworkよりもはるかに優れた特定のデータベースバージョンを実際にバージョン管理するための優れたツールですが、機能します。たとえば、すべての機能を記録します。私が持っているデータベースのどれでも、最初にコードを使用することはほとんどできません-少なくともフィルターされたインデックスを常に持っているためです;）EFは私が必要なものの10％にさえ到達しません。

私たちのアプローチは：

• データベース内のデータベースを設計し、チェックインされるSSDTモジュールに同期します。スキーマ同期により、開発者はバージョンをすばやく更新できます。常に現在のバージョンの信頼できるマスターデータベースがどこか（特別なサーバー上）にあるため、参照バージョンがあります。

• バージョン管理され、データベースに展開するための優れたメカニズムを備えたリリースに必要なデルタスクリプトを生成します。

SQL ServerデータベースでEFを使用する方法は複数あります。

1. Code-First ...クラスを作成すると、EFは関連するテーブルを生成します
2. 最初にデータベース...テーブルを設計し、EFがクラスを生成します。

EFは必ずしもすべての作業をあなたのために行うわけではありません。EFは約80〜95％をそこに連れてきます。データベース開発の残りの5〜20％は、ビューやストアドプロシージャなどの最適化によって補完されます。

いいえ、直交していません。ただし、全体的な設計戦略を決定し、EFが理想的な結果にならない部分を最適化するためにSSDTなどのツールに依存する必要があります。