テーブルごとにADO.NET Entity Data Modelを作成する必要がありますか、それともデータベース全体に1つ作成する必要がありますか？

Question

各テーブルに1つのADO.NETエンティティデータモデルを使用することになっていますか？または、リレーションシップもルーティングされるデータベース全体用など...

Answer 1

データベース全体に対して実行します。すべてのテーブルのデータモデルを作成する場合、関係をナビゲートする利点はありません。

Subversionのようなチェックアウト/マージソース管理を使用している場合、デザイナはSubversionがマージに苦労する程度にXMLを変更することに注意してください。この場合、通常は毎回モデル全体を再生成するか、手動でマージする必要があります。

Answer 2

関連テーブルにエンティティデータモデルを使用しています。データベースのサイズに応じて、テーブルが20個または25個未満の場合にモデルを1つだけ作成します。各モデルには作成するEntityConnectionオブジェクトがあるため、すべてのテーブルに個別のモデルを作成するのは少し費用がかかります。

5〜15個のテーブルがある場合、モデルをかなり適切に保守できることがわかります。私の主な決定要因は機能性です。エンジニアリングアプリケーションを構築しているため、たとえば、構造用鋼コンポーネントのテーブルが約6つあります。これらはすべて1つのモデルです。これらは共通のエンジニアリング属性を共有しているため、それらの属性の操作に固有のコードを再利用しやすくなります。

これは、一般的なコードファイル内でモデルをインスタンス化し、オブジェクトを作成し、それらのオブジェクトを操作/整理できることを意味します。データベースに戻す必要がある変更は、非常に効率的に実行できます。

要点は、基礎となるオブジェクトの必要性と使用頻度を決定することです。 1つまたは2つのテーブルを絶えず更新する場合、そのモデル内に他の30の無関係なテーブルを置くことは意味がありません。少数のテーブルが頻繁に使用されるこのシナリオでは、これらのオブジェクトのコレクションを作成し、コレクションを操作し、適切なタイミングでデータベースを更新することが理にかなっています。

メモリ操作は、ディスクI / Oを実行するよりもはるかに安価です。これはフレームワークに対する私の見解であり、決して専門家ではありません。

Answer 3

データベース全体または少なくとも使用するテーブルに1つ...

大量のテーブルがある場合、それらをスキーマまたはその他のカテゴリに分割できますが、アイデアはテーブルごとのデータモデルではなかったと言えます...

Answer 4

データベーススキーマとは無関係にデータの概念/オブジェクトモデルを設計し、概念モデルをデータベーススキーマに最もよく関連付けるマッピングを作成します。すべてではないにしても、ほとんどのテーブルを使用する場合があります。テーブルへの1対1のマッピングが必要な場合は、LINQ-to-SQLを使用する方が簡単なため、代わりにLINQ-to-SQLを検討することもできます。

Answer 5

上記の回答に加えて、EFモデルは実際には概念レベルにあることに留意してください。データベースの構造に関係する必要はなく、データベース全体を表す必要はありません。

Answer 6

データベースが大きい場合は、データベーステーブルを分類する必要があると思います。ただし、ado.netエンティティフレームワークの主要な要件であるテーブルごとにクラスを作成する必要があります。

データベースを更新すると、データモデルの更新を行うことができます。

まずデータベースを設計してから、ado.netエンティティモデルを作成します。