3

match table ( id , details)andがteam table (id,name) あり、指定された 2 つのチームによってすべての試合が行われるようにしたい場合。

私の解決策は次のとおりです。

on を含む 3 番目のテーブルを作成する(match_id,team1_id,team2_id)

これはこの場合のベストプラクティスですか?

4

2 に答える 2

2

3 番目のテーブルは必要ありません。matchテーブルから直接チームを参照してください。

ここに画像の説明を入力

明確にするために、同じチームのペアが複数の試合に参加できるようにするために、 をキーにする{team1_id, team2_id}べきではありません。もちろん、適切な FK とCHECK(team1_id <> team2_id).

特定のチームが試合を行うには、..

SELECT ... WHERE team1_id = :given_team_id OR team2_id = :given_team_id

...上の図のI1とで示されているように、両方のチーム ID にインデックスが必要です。I2

また、パフォーマンス上の理由から、これらのインデックスを広くすることを検討してください。たとえば、フィールドの限られたサブセットのみを取得する場合...

SELECT team1_id, team2_id FROM ...

...そしてこれらのフィールド (および) をカバーするようにインデックスを拡張すると、クエリを満たすために DBMS がテーブル ヒープにまったくアクセスする必要がなくなります。I1: {team1_id, team2_id}I2: {team2_id, team1_id}

あるいは、次のような自然キーの使用を検討することもできます。

ここに画像の説明を入力

これにより、インデックスの 1 つ (サロゲート PK: の下にあるもの) を削除できますが{match_id}、もちろん、ダウンストリームの FK が「より太い」ものになります。

クエリのニーズに応じて、PK フィールドの順序をいじることができます。

  • たとえば、クエリの大部分が「過去 X 日間に行われた試合を教えてください」と尋ねる場合は、最match_date前面に移動することを検討してください。
  • クエリの大部分がいつでも行われる試合を要求する場合は、それを後ろに置いてください。
  • 両方の場合は、追加のインデックスが必要になります。

ところで、3 つ目のテーブルを持つことは{match_id, team_id}、2 つ以上のチームがプレーできる試合 (セーリングなど) に適しています。また、1 つまたはゼロのチームしか許可しないという残念な機能もあります。これは、おそらく非宣言的な方法で防御する必要があるものです。

上記の設計により、正確に 2 つのチームが存在することが保証されます。

于 2012-10-12T11:29:44.107 に答える
1

試合は 2 つのテーブルでのみプレーできると仮定すると、team1_id と team2_id はmatch属性としてテーブル自体の一部である必要があります。別のテーブルは必要ありません。team1_id と team テーブルの id の間に FOREIGN KEY 関係を定義することもできます。team2_id についても同様です。

複数のチームがプレーできる試合には 3 番目のテーブルが必要です。その場合、テーブル構造は ( match_id, team_id) になり、同じ match_id を持つ複数のレコードが存在します。つまり、試合テーブルと match_teams テーブルの間に 1 対多の関係があります。 .

于 2012-10-12T04:30:16.267 に答える