6

他のテーブルの主キーへの外部キーであるint列が2つしかないinnoDbsがいくつかあります。

たとえば、1つのテーブルはuser_itemsであり、userId、itemIdの2つの列があり、両方ともuserテーブルとitemテーブルへの外部キーであり、更新または削除されるとカスケードに設定されます。

そのようなテーブルに3番目の列を追加してそれを主キーにする必要がありますか、それともパフォーマンスやその他の利点の観点から、現在の状態の方が優れていますか？

4

3 に答える 3

6

ID 列を追加するためだけに 3 番目の ID 列を追加しても意味がありません。実際には、行を挿入または削除するときに、処理のオーバーヘッド (インデックスのメンテナンス) が追加されるだけです。

主キーは必ずしも「ID 列」ではありません。

ユーザーとアイテムの間で単一の関連付けのみを許可する場合 (ユーザーに同じアイテムを 2 回割り当てることはできません) (userid, itemid)、テーブルの主キーとして定義することは理にかなっています。

同じペアが複数回出現することを許可する場合、もちろんその制約は必要ありません。

于 2012-06-24T09:59:28.680 に答える
2

あなたはすでに自然キーを持っています{userId, itemId}。別の（代理）キーを追加する特別な理由がない限り、既存のキーをプライマリとして使用してください。

代理の理由には次のものがあります。

  • 子FKを「スリム」に保つ。
  • 子カスケード更新の排除。
  • ORM-親しみやすさ。

これはあなたの場合には当てはまらないと思います。

また、 InnoDBテーブルはクラスター化されており、クラスター化テーブルのセカンダリインデックスは、ヒープベースのテーブルのセカンダリインデックスよりもコストがかかることに注意してください。したがって、理想的には、可能な限りセカンダリインデックスを避ける必要があります。

于 2012-06-24T10:50:25.547 に答える
0

一般に、作成するコードに実際の複雑さが加わらず、テーブルに含まれる行が100,000〜500,000行以下であると予想される場合は、主キーを追加することをお勧めします。created_atまた、列を追加することをお勧めすることもありupdated_atます。

はい、より多くのストレージが必要ですが、最小限です。また、主キーインデックスを維持する必要があるため、テーブルが大きくなると挿入と更新が遅くなる可能性があるという問題もあります。ただし、テーブルが大きくない限り（数十万または数百万行）、処理速度に違いはありません。

したがって、テーブルが非常に大きくならない限り、スペースと処理速度への影響は重要ではありません。したがって、テーブルを維持するために必要な労力と、テーブルが提供する潜在的なユーティリティを決定します。余分なコードをほとんど必要としない場合は、それが提供する実質的にすべてのユーティリティが価値のあるものになる可能性があります。

主キーを使用する最も良い理由の1つは、挿入された順序に基づいて行に自然な順序を与えることです。追加された最後の100（または最初の100）行を取得したい場合、テーブルに自動インクリメントの主キーがあれば、非常に簡単で高速です。

列を追加するinserted_atとupdated_at、日付範囲に基づいてデータをフェッチするという点で同様のユーティリティを提供できます。繰り返しますが、行数が非常に多くならない限り、これらも評価する価値があるかもしれません。

于 2012-06-24T10:43:47.900 に答える