2

いくつかのラベルを保持する最大5つのレコードを持つ非常に小さなテーブルがあります。私はPostgresを使用しています。

構造は次のとおりです。

id-smallintラベル-varchar（100）

このテーブルは、主に他のテーブルの行を参照するために使用されます。問題は、IDに主キーを設定する必要があるのか​​、IDにインデックスのみを設定する必要があるのか​​、それとも両方を設定する必要があるのか​​ということです。

私はインデックスと主キーについて読みましたが、これはテーブルが何に使用されるかに大きく依存することを理解しています。

主キーのないテーブル

編集：主キーまたはインデックス、あるいはその両方を持っているかどうかを尋ねるつもりでした。質問を編集しました。

4

5 に答える 5

4

主キー列を用意することは常に良い習慣です。必要な典型的なシナリオは、行を更新または削除する場合です。PKを使用すると、行がはるかに簡単かつ安全になります。

于 2009-02-17T13:42:33.737 に答える
2

はい、主キーは良い習慣であるだけでなく、非常に重要です。一意のキーがないテーブルは、第 1 正規形ではありません。

他のテーブルがこのテーブルを外部キーで参照するようにする場合は、PRIMARY KEY または UNIQUE 制約を宣言する必要があります。

ほとんどの RDBMS ブランドでは、PRIMARY KEY 制約と UNIQUE 制約の両方が暗黙的に列にインデックスを作成します。これを暗黙的に行わない場合は、制約を宣言する前に自分でインデックスを定義する必要がある場合があります。

于 2009-02-17T13:56:11.070 に答える
1

はい、同じIDを共有する2つのラベルは必要ないため、idフィールドに主キーが必要になります。

また、このテーブルでの検索/ルックアッププロセスを高速化するために、インデックスが必要です（ただし、小さなテーブルの場合、パフォーマンスの向上は少なくなります）。このシーケンスは、次のIDを入力するのに役立ちます。以前の値を既存の値に変更することを妨げるものではありません。

于 2009-02-17T13:43:36.730 に答える
0

開発者の観点からは、列の 1 つにとをPRIMARY KEY組み合わせただけです。NOT NULLUNIQUE INDEX

AUNIQUE INDEXは次の場合に適しています。

  1. 一意性を強制する必要があります。これを行うには、index を使用するのが最も効率的な方法です。
    • を実行するかSELECT、インデックス付きフィールドで選択的な条件を使用する必要があります。つまり、クエリの影響を受ける行の数は、行の総数 (たとえば、 の行) よりもはるかに少なくなります。UPDATEDELETEWHERE102,000,000

次の場合、 AUNIQUE INDEXは不適切です。

  1. もちろん、このフィールドに一意性は必要ありません:)しかし、各レコードを識別できるように、テーブルに一意のインデックスを1つ用意することをお勧めします。
    • あなたは速くする必要がありますINSERTS
    • インデックス付きフィールドで選択的ではない条件で、インデックス付きの値の高速なUPDATEとが必要です。つまり、クエリの影響を受ける行の数は、行の総数 (たとえば、 の行) に匹敵します。DELETEWHERE1,500,0002,000,000

小さなテーブルを作る予定なので、そのPRIMARY KEY上に を作成することをお勧めします。

于 2009-02-17T14:13:11.980 に答える