テーブルごとに1つのADO.NETエンティティデータモデルを使用することになっていますか？または、関係もルーティングされるデータベース全体用に1つなど...
2122 次
6 に答える
6
データベース全体に対して実行します。すべてのテーブルのデータモデルを作成する場合、関係をナビゲートする利点はありません。
Subversionのようなチェックアウト/マージソース管理を使用している場合、デザイナーは、SubversionがXMLをマージするのに苦労する範囲でXMLを変更することに注意してください。この場合、通常、モデル全体を毎回再生成するか、手動でマージする必要があります。
于 2009-06-22T18:38:21.883 に答える
2
関連するテーブルにはエンティティデータモデルを使用しています。データベースのサイズに応じて、テーブルが約20または25未満の場合、モデルを1つだけ作成します。各モデルには作成するEntityConnectionオブジェクトがあるため、テーブルごとに個別のモデルを作成するのは少しコストがかかります。
テーブルが5〜15個あれば、モデルをかなりうまく維持できることがわかります。私の主な決定要因は機能性です。私はエンジニアリングアプリケーションを構築しているので、たとえば、構造用鋼コンポーネントのテーブルが約6つあります。それらはすべて1つのモデルに含まれています。これらは共通のエンジニアリング属性を共有しているため、これらの属性の操作に固有のコードを再利用する方が簡単です。
これは、モデルをインスタンス化し、オブジェクトを作成し、それらのオブジェクトを共通のコードファイル内で操作/整理できることを意味します。データベースに伝播する必要のある変更は、非常に効率的に実行できます。
肝心なのは、基礎となるオブジェクトの必要性と使用頻度を決定することです。1つまたは2つのテーブルを絶えず更新する場合は、そのモデル内に30の他の無関係なテーブルを含めることは意味がありません。少数のテーブルが頻繁に使用されるこのシナリオでは、これらのオブジェクトのコレクションを作成し、コレクションを操作して、適切なタイミングでデータベースを更新することが理にかなっている場合があります。
メモリ操作は、ディスクI/Oよりもはるかに安価に実行できます。これはフレームワークに対する私の見解であり、決して私はその専門家ではありません。
于 2009-06-22T18:55:55.787 に答える
1
1つはデータベース全体、または少なくとも使用するテーブル用です...
大量のテーブルがある場合は、それらをスキーマまたはその他のカテゴリに分割できますが、そのアイデアはテーブルごとのデータモデルではなかったと思います...
于 2009-06-22T18:36:37.083 に答える
1
データベーススキーマとは独立してデータの概念/オブジェクトモデルを設計し、概念モデルをデータベーススキーマに最もよく関連付けるマッピングを作成します。すべてではないにしても、ほとんどのテーブルを使用する可能性があります。テーブルへの1対1のマッピングが必要な場合は、操作が簡単なため、代わりにLINQ-to-SQLを検討することをお勧めします。
于 2009-06-22T18:42:07.633 に答える
1
上記の回答に加えて、EFモデルは実際には概念レベルであることに注意してください。データベースの構造とは何の関係もありませんし、データベース全体を表す必要もありません。
于 2009-06-22T20:31:11.700 に答える
-1
大規模なデータベースを使用している場合は、データベーステーブルを分類する必要があると思います。ただし、ado.netエンティティフレームワークの主要な要件であるテーブルごとにクラスを作成する必要があります。
データベースを更新すると、データモデルの更新を行うことができます。
最初にデータベースを設計し、次にado.netエンティティモデルを作成します。
于 2009-06-22T18:41:52.707 に答える