2

次のフィールドを持つテーブルがあるとします。

  • リーグID
  • マッチID
  • 一部のデータ

リーグでは多くの試合が開催されます。通常、各リーグは独自のローカル データベースを使用するため、LeagueID フィールドはこのローカル データベースのすべてのレコードで同じになります。年に一度、リーグはそのデータを各国当局にアップロードします。その後、同じ MatchID を持つ試合を識別するために LeagueID が必要になります。

(EF Fluent API を使用して) 複合主キーを実装する最良の方法は何ですか?

Entity<Match>.HasKey(match=>new {match.LeagueID,match.MatchID})

また

Entity<Match>.HasKey(match=>new {match.MatchID,match.LeagueID})

人間の目には、リーグ - 試合の順序は論理的であり、特定のリーグの試合がまとめて保持されます。しかし、複合キーを作成するときは、パフォーマンス上の理由から、最も識別力の高いフィールドを最初に使用することが重要であることを理解しました。

4

2 に答える 2

5

ケーキを持って食べてもいいと思います。

データベース
データベースにキーを実装する場合、一般に、より選択的なフィールドを持つ狭いキーを使用すると、パフォーマンスが向上します。これは、単一キーと複合キーに当てはまります。クエリ パターンに実際には一致しない、より選択的なインデックスはほとんど役に立たない可能性があるためです。たとえば、複合キーでは、MatchIDが最初 (より選択的) であるが、より頻繁にクエリを実行するLeagueID(選択的でない) 場合、選択性はあなたに不利に働きます。

本当の問題は、インデックス A または B がより選択的であるということではなく、「クエリを実行する方法に適したインデックスがありますか?」ということだと思います。(そしてデータの整合性を強制しますが、それは別の議論です)。したがって、このテーブルをクエリする方法を理解する必要があります。次のようにクエリする場合:

  • LeagueIDほとんどの場合 -- インデックスLeagueID, MatchID
  • MatchIDほとんどの場合 -- インデックスMatchID, LeagueID
  • コンポジットLeagueID&MatchIDほとんどの場合 -- インデックス MatchID, LeagueID
  • 混合バッグ -- 注文ごとに 1 つずつ 2 つのインデックスが必要な場合がありますが、2 つのインデックスを維持するための余分なオーバーヘッドが挿入/更新/削除のヒットに値するかどうかを判断する必要があります。

EF とクエリほとんどの場合、クエリ
内の列の順序(または EF で一致を作成する方法) は違いはありません。つまり 、 と同じクエリ プランとパフォーマンスが得られます。 where a=@a and b=@bwhere b=@b and a=@a

SQL Server を使用していると仮定すると、where 句を記述する順序はほとんど問題になりません。オンラインの本は、この問題を簡潔に説明し、次のように述べています。

論理演算子の評価の順序は、クエリ オプティマイザーによる選択によって異なります。)。

于 2013-02-01T14:31:57.297 に答える
0

HasColumnOrder を使用して、データベース内のフィールドの順序を選択できます。

于 2013-02-01T14:31:41.090 に答える