web-dev-qa-db-ja.com

独立協会と外部キー協会とは何ですか？

重複の可能性：
コードファースト：独立した関連付けと外部キーの関連付け？

EF4またはEF5コードファーストでは、 MSDN または 外部キーと独立関係で使用される「独立した関連付け」とは何であり、「外部キーの関連付け」とは何ですか。 ？ - Entity Frameworkの5 （強調追加）とが改善です。

2.4.1ビュー生成コストを削減するための外部キーアソシエーションの使用

モデル内の関連付けを独立した関連付けから外部キーの関連付けに切り替えると、ビューの生成に費やされる時間が劇的に改善されるケースが数多く見られます。

だから-今私はどちらを使うべきかを知っています。それらが何であるか、そしてどのようにそれに変換するかを私が知っていれば！では、私の質問は、これらの用語をどのように定義するのかということです。どのような流暢/注釈/慣習がそれぞれを呼び出しますか？

c#entity-framework-4entity-framework-5
18
Scott Stafford

外部キーの関連付けは、対応するナビゲーションプロパティに加えて、モデルに外部キープロパティがある場所です。独立した関連付けとは、データベースに外部キー列があるが、この列に対応する外部キープロパティがモデルにない場合です。つまり、NavigationPropertyはありますが、のID値を示す外部キープロパティがありません。関連プロパティは、実際には関連プロパティに移動しません。

独立した関連付けを持つモデルの例を次に示します（依存関係には外部キーがなく、ナビゲーションプロパティのみがあることに注意してください）。

public class Dependent
{
    public int Id { get; set; }

    [Required]
    public Principal PrincipalEntity { get; set; }

}

public class Principal
{
    public int Id { get; set; }
    public ICollection<Dependent> DependentEntities { get; set; }
}

public class MyContext : DbContext
{
    public DbSet<Dependent> Dependents { get; set; }
    public DbSet<Principal> Principals { get; set; }
}

これは同じモデルの例ですが、ForeignKey Associationがあります（PrincipalEntity_Idプロパティと[ForeignKey（）]属性に注意してください）。

public class Dependent
{
    public int Id { get; set; }

    public int PrincipalEntity_Id { get; set; }

    [Required]
    [ForeignKey("PrincipalEntity_Id")]
    public Principal PrincipalEntity { get; set; }

}

public class Principal
{
    public int Id { get; set; }
    public ICollection<Dependent> DependentEntities { get; set; }
}

public class MyContext : DbContext
{
    public DbSet<Dependent> Dependents { get; set; }
    public DbSet<Principal> Principals { get; set; }
}

データベースは変更されないことに注意してください。基になるデータベースには常に外部キーの列がありますが、独立した関連付けでは公開されませんでした。

外部キーの関連付けを使用すると、外部キーの値を変更するだけで関係を更新できます。これは、ナビゲーションプロパティを更新するエンティティをロードする必要がないため、値がわかっている場合に便利です。

27
Pawel

独立キーまたは外部キーの関連付けを使用する理由についての私の意見：

独立した協会

長所：

  • これは、オブジェクト指向の世界に行く正しい方法です。オブジェクト指向の世界では、いくつかの魔法の鍵ではなく、集合体内の参照を使用しています。

短所：

  • 純粋なPOCOでは、どちらの場合も参照がnullであるため、主関係が本当にNULLであるか、単にロードされていないかがわかりません。これらの2つのnullを区別するようにコンテキストに要求する必要があります。これは、主要エンティティへのすべてのナビゲーションプロパティがEntityObjectの接尾辞が付いた別のプロパティとペアになっていて、関係に関する追加の詳細を提供する、重いReferenceベースエンティティでは問題ではありませんでした。
  • 独立した関連付けを管理するEFの方法は、特に分離天体グラフの添付に関しては非常に複雑です。それぞれの独立したアソシエーションには独自の状態があり、Modified状態になることはありません。すべての変更は常に、古いリレーションを削除済みとして設定し、新しいリレーションを追加済みとして作成することで構成されます。これは、使用しようとすると本当に混乱します。
  • 独立した関連付けにより、EFの初期化中（またはビューの事前生成中）にビューの生成が大幅に遅くなることが報告されました。
  • 独立した関連付けは、外部キーのみをバインドする必要があるデータバインディングシナリオで使用するのがはるかに難しい場合があります。

外部キー協会

長所：

  • シンプル。キープロパティは管理が簡単で、独立したアソシエーションのすべての問題を解決します-外部アソシエーションの状態がない、直接データバインディング、関係が存在する場合（キーがnullでない）の即時可視性など。

短所：

  • それらは概念的に間違っており、EFでそれらを提供することは、オブジェクトの世界からリレーショナルの世界への大きな一歩でした。 EFv1とEFv4の間で大きな重大な変更を引き起こす可能性があるとしても、正しい解決策は、独立した関連付けの処理方法を改善または変更したと今でも信じています。また、動作がまったく異なる2種類の関連付けがある現在の状況も好きではありません。明確に定義された動作とオプションの外部キープロパティがエンティティに公開されているタイプは1つだけである必要があります。

1対1は常に外部キーの関連付けであり、多対多は常に独立した関連付けであるため、この違いは1対多の関連付けにのみ重要です。

35
Ladislav Mrnka