2

相互に関連する3つのエンティティがあります。

  • Fooにはたくさんの添付ファイルがあります
  • バーには多くのアタッチメントがあります
  • 各添付ファイルは、FooまたはBarのいずれかに属することができます。

これを使用してモデル化する最良の方法は何DbModelBuilderですか？

試してみると：

modelBuilder.Entity<Foo>().HasMany(t => t.Attachments).WithOptional()
    .Map(m => m.MapKey("FOO_ID")).WillCascadeOnDelete(true);
modelBuilder.Entity<Bar>().HasMany(t => t.Attachments).WithOptional()
    .Map(m => m.MapKey("BAR_ID")).WillCascadeOnDelete(true);

これはあまりクリーンなデータモデルではありません。*添付ファイルテーブルには、可能な親エンティティ（'FOO_ID'、'BAR_ID'）ごとに1つずつ、2つのFK列があります。添付ファイルを必要とするエンティティの数を増やすと、テーブルが肥大化します。*もちろん、アタッチメントは常にエンティティにアタッチされますが、後方参照をオプションにする必要があります。必ずしもFooである必要はなく、Barである必要もありません。ただし、すべてのFKがNULLに設定されている添付ファイルは、ビジネスビューからは有効ではありませんが、スキーマによって許可されます。*理論的には、1つのアタッチメントがFooとBarの両方にリンクされている可能性がありますが、これは無効です。

代わりに、関係をジャンクションテーブル「T_FOO_ATTACHMENT」および「T_BAR_ATTACHMENT」にマップする場合があります。* T_FOO_ATTACHMENTには、Fooへの必須外部キー（FOO_ID）と添付ファイルへの必須FK（ATTACHMENT_ID）があります。*同じことがT_BAR_ATTACHMENTにも当てはまります

欠点：*アタッチメントは引き続きFooとBarにリンクできます。*添付ファイルが複数のFooにリンクされている可能性もありますが、これも無効です。理想的には、流暢な構文を使用して、それを防ぐDB制約を追加できます。

4

1 に答える 1

2

これはあまりクリーンなデータモデルではありません。添付ファイルテーブルには、可能な親エンティティ（'FOO_ID'、'BAR_ID'）ごとに1つずつ、2つのFK列があります。

しかし、リレーショナルの観点からは絶対に正しいです。別のテーブルとの関係が必要な場合は、新しい外部キーが必要です。

ただし、すべてのFKがNULLに設定されている添付ファイルは、ビジネスビューからは有効ではありませんが、スキーマによって許可されます。理論的には、1つのアタッチメントがFooとBarの両方にリンクされている可能性がありますが、これは無効です。

それがあなたのビジネスロジックです。現在のモデルでは、アプリケーションでそれを適用する必要があります。

Attachment探しているのは、FKだけでなく、関連するテーブルの名前も含まれる、ある種の名前付きリレーションです。これは、リレーショナルレベルでは達成できないことです。これは、データレベル（これもビジネスロジック）であり、EFでマッピングすることはできません。

于 2012-06-04T14:18:08.503 に答える