4

レガシー データベース システムを .NET + Entity Framework 6 (コード ファースト POCO) + PostgreSQL にアップグレードしています。プログラミングを簡単にするために、大きなテーブル (200 以上のフィールド) を複数のエンティティに分割したいと考えています。

Franchise
FranchiseLegalEntity
FranchiseBilling
FranchiseSignup
FranchiseAllocation
FranchiseCompliance
FranchiseMiscellaneous
FranchiseNotifications

EF6 が「テーブル分割」をサポートしていることを知り、うれしく思いました。単一のテーブルを複数のエンティティにマッピングして、フィールドを分割します。

ただし、これを実装しようとしてオンラインで多くのページを読んだところ、複数回分割すると問題があることが確認されました。Entity Framework では、プリンシパル エンティティだけでなく、テーブルにマップされたすべてのエンティティ間のナビゲーション プロパティが必要です。上記の私のシナリオでは、これには 21 個の無意味なナビゲーション プロパティが必要です。わざわざ双方向にするのであれば 42 個です。

参照: http://social.msdn.microsoft.com/Forums/en-US/0f65caae-8a66-431f-aa02-4b2c68f871e9/ef-41-rc-code-first-split-one-table-into-multiple- entities?forum=adodotnetentityframework

参照: EF-Code-First を使用して大きなテーブルを複数の個別の型に分割する方法

共有主キーを持つ複数のテーブルを使用することをお勧めします。私にとってはオプションです。ただし、EF の肥大化した SQL クエリ生成と、複雑なクエリを使用する PostgreSQL の場合によってはでたらめなクエリ オプティマイザを考えると、このオプション (100GB 以上のデータベース) のパフォーマンスに懸念があります。

要約する：

テーブル分割

長所: 最高のクエリ パフォーマンス、データベース レイヤーでの実装が最も速い

短所：私のモデルとOnModelBuilding（）メソッドをがらくたで汚染し、他の開発者を混乱させます

複数のテーブルで主キーを共有

長所: 最もクリーンなモデルとコード、非レガシー データベースに推奨されるソリューション

短所: 実装に余分な作業が必要で、パフォーマンスが低下する可能性があります

私の質問:

1) EF6 は 2 つ以上の分割でテーブル分割を改善しましたか?

2) 考慮していない要因はありますか?

3) 他に選択肢はありますか?

PS [ComplexType] の使用には興味がありません

4

2 に答える 2

1

多くの仮定を使用して、フィールドの必要なサブセットを BCP アウトし、BCP インして目的の DB テーブルに戻そうとする場合があります。BCP-out SQL ステートメントはユーザーが制御できるため、これは単純で反復可能なプロセスであり、常にデータの一部のみ (たとえば、特定の日付以降に作成されたレコードのみ) をエクスポートできます。ただし、データ量が膨大なため、うまくいかない場合があります。

于 2014-01-14T07:55:35.653 に答える
1

私が解決した解決策は、テーブル分割オプションです。

これには、多くの無意味なナビゲーション プロパティをモデルに追加し、流暢な API に依存することが含まれます。オーバーヘッドを最小限に抑え、潜在的なパフォーマンスの問題を回避するため、2 つの悪のうち小さい方だと思います。

このスレッドで、ソリューションの詳細 (コードを含む) の概要を説明しました。

EF6 はテーブル分割/共有主キー + 基本クラスのモデルを構築できませんか?

于 2014-01-15T08:43:48.627 に答える