2

私はかなり単純な問題追跡アプリにエンティティ フレームワークを使用しています。次のような追加のプロパティを追加して、「Issue」エンティティを拡張する機能をユーザーに提供したいと思います。

  • 数値フィールド
  • テキスト フィールド (シンプルまたはリッチ テキスト)
  • 異なるリスト (複数\単一選択)
  • ブール値のプロパティ

このタスクを達成するために、次の 2 つの方法を考えました。

拡張可能なデータベース アプローチ

これは単なるアイデアであり、Entity Framework を使用して実装する方法がわからないので、あなたの助けをお待ちしています。基本的な概念は次のとおりです。

  1. タイプと名前、および場合によってはその他のプロパティを説明する各フィールドのレコードを持つ、IssueExtendedFields というテーブルを作成します。
  2. 各「リスト タイプ フィールド」のオプションのリストを保持する IssueFieldOptions という別のテーブルを作成します。
  3. 最終的なテーブルは、IssueExtendedFieldValues という名前で、ユーザーが作成したカスタム フィールドごとに特定の命名規則を持つ列と、課題ごとの外部キーを保持します。

エンティティフレームワークを使用し、テーブルから生成されるEFエンティティオブジェクトがあるため（DBが最初）、理論的には新しい列ごとにDALを再マップして再コンパイルする必要があるため、3番目のステップを実装する方法がわかりません事業。

他に提案はありますか？

辞書的アプローチ

このアプローチは、実装方法を知っています

  1. タイプと名前、および場合によってはその他のプロパティを説明する各フィールドのレコードを持つ、IssueExtendedFields というテーブルを作成します。
  2. 各「リスト タイプ フィールド」のオプションのリストを保持する IssueFieldOptions という別のテーブルを作成します。
  3. そして、システムに入力された各「フィールド - 値」ペアのレコードを保持する IssueExtendedFieldValues という名前の最終テーブル

しかし、それには多くの欠点があります (それらを克服する方法がわかっている場合は、投稿してください)。

  1. ユーザーが追加するすべての新しいプロパティは単なる別のレコードであり、各エンティティに格納されているデータ量に X を掛けます。ここで、X はプロパティの数です。大量の問題がシステムに入り、さらに 10 個のレコードを保持する別のテーブルが作成されます。 for each issue は、大量のメモリを必要とする巨大なクエリを生成します。
  2. 予想されるメモリの問題に加えて、レポートやビューのような動的な「ピボット」を作成して、ユーザーがカスタム プロパティのレポートを再度生成できるようにする必要があります。膨大な量のデータを処理する場合、「ピボット」クエリにはさらに時間がかかります。 .
4

2 に答える 2

3

この質問はかなり古いものであることは承知していますが、特定の瞬間のデータベース スキーマが何であれ、実行時に EF データ モデルを構築することを妨げるものは何もありません。ほとんどのデータ モデルは静的であるため、追加された複雑さは、実行時に変更できるエンティティにローカライズされます。

  1. 実行時にデータベースに列を追加すると、対応する型にプロパティを追加する必要があります。これは、型が実行時に構築されることを意味します。場合によっては、追加のプロパティを使用して実行時に派生型を作成する(または何らかのインターフェイスを実装する) ことで、コンパイル時のコードが他の方法で動作する妥当な型になるようにします。これはReflection.Emitを使用して実現できます。

  2. スキーマが変更されるたびに、実行時に EF マッピングを動的に構築する必要があります。これは EF Code First で行うことができます。マッピングが通常の EF Code First 規則に適合している場合は、実行時の型がマッピングに追加されていることを確認する以外に、ここで行う必要があることは何もありません。それ以外の場合は、実行時に追加のプロパティに必要なマッピングを決定および構成するコードを実装する必要があります。

  3. 追加のプロパティを利用するクエリは、実行時に動的に構築する必要があります。これは、LINQ クエリで使用するメンバー アクセス式を作成することを意味します。同様に、実行時にのみ認識される追加のプロパティの値にアクセスするには、リフレクションが必要です。

Entity-Attribute-Value (EAV) データ モデリングとしてより広く知られている 2 番目のアプローチに用心するのは正しいことです。このアプローチには多くの欠点がありますが、結合やクエリの複雑さが増し、外部キーのサポートが不足していることは特に重要ではありません。ただし、EAV モデルはコンパイル時に宣言されるため、間違いなく実装が簡単です。

または、ドキュメント データベースなど、柔軟なスキーマを持つエンティティ専用の別のデータ ストアの使用を検討することもできます。

于 2014-11-12T23:41:49.927 に答える
0

したがって、新しい各列は、理論的にはDALプロジェクトを再マップして再コンパイルする必要があります。

あなたはあなた自身の質問に答えました:)EFは固定データベーススキーマで動作するので、最初のオプションはとにかくオプションではありません。

于 2013-02-22T11:25:13.983 に答える