sql - SQL: 主キーにするか、主キーにしないか?

Question

ユーザーの設定のセットを含むテーブルがあり、次の列があります。

UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME

UserID と Set および Key は一意です。そのため、特定のユーザーが特定の設定セットで同じキーを 2 つ持つことはできません。設定はセットごとに取得されるため、ユーザーが特定のセットから特定のキーを要求すると、セット全体がダウンロードされるため、次に同じセットのキーが必要になったときにデータベースにアクセスする必要はありません。 .

3 つの列すべて (ユーザー ID、セット、およびキー) に主キーを作成する必要がありますか、または主キーを持つ追加のフィールドを作成する必要があります (たとえば、SettingID と呼ばれる自動インクリメント整数、悪い考えです)、または主キーを作成しないでください。キーを作成し、一意のインデックスを作成するだけですか?

- - - アップデート - - -

わかりやすくするために、これは行末テーブルであり、結合されていません。UserID は、Users テーブルの FK です。セットは FK ではありません。私のGUIのヘルパーテーブルです。例として、ユーザーが Web サイトの一部に初めてアクセスすると、必要に応じて閉じることができるヘルプバルーンが表示されます。クリックして離れたら、"GettingStarted" セットにいくつかの設定を追加し、バルーン X が無効になっていることを示すようにします。次にユーザーが同じページにアクセスすると、ヘルプバルーン X が表示されないように設定されます。

score 7 · Accepted Answer

複合一意キーを持つことは、ほとんどの場合良い考えではありません。

ビジネス関連のデータを主キーとして持つことも、問題を引き起こす可能性があります。たとえば、値を変更する必要がある場合。アプリケーションで値を変更できない場合は、将来変更される可能性があるか、アップグレードスクリプトで変更する必要があります。

ビジネス上の意味を持たない自動番号である代理キーを作成することをお勧めします。

更新後に編集します。

この場合、概念的に主キーを持たないと考えて、この 3 つの列を複合一意キーの主キーにする (変更可能にする) ことができます。

score 2 · Accepted Answer

3 つの列すべてに主キーを作成する必要がありますか(userid, set, and key)

これを作ってください。

代理主キーを使用すると、他の目的に使用されない余分な列が作成されます。

UNIQUE INDEXサロゲート主キーとともにを作成することは、クラスタ化されていないを作成することと同じPRIMARY KEYであり、余分なKEY lookupものが発生し、パフォーマンスが低下します。

willUNIQUE INDEXなしで aを作成すると、値にアクセスするために追加のものが必要なテーブルが作成されます。これもあまり良くありません。PRIMARY KEYHEAP-organizedRID lookup

score 1 · Accepted Answer

キーとセットはいくつありますか? これらは varchar(50) である必要がありますか、それともルックアップテーブルを指すことができますか? この Set と Key を SetId と KeyId に変換できる場合は、3 つの整数値で主キーを作成すると、はるかに高速になります。

score 0 · Accepted Answer

私は複合キーの支持者ではありませんが、この場合、ラインテーブルの終わりとして、それは理にかなっているかもしれません。ただし、挿入時に1つ以上の値が不明であるために、これら3つのフィールドのいずれかでヌルを許可すると、問題が発生する可能性があり、一意のインデックスの方が適している場合があります。

score 0 · Accepted Answer

UserID を 32 ビットの newid() または一意の識別子として使用することをお勧めします。これにより、複合キーの問題も解決します。

score 0 · Accepted Answer

おそらく、コード全体で UserID を重複させるのではなく、UserID が一意の識別子であることを確認しようとするでしょう。複合キーは、コードの後半で混乱する傾向があります。

これはある種の構成値の検索フィールドであると想定しているため、その場合はおそらく複合キーを使用できます。データはすでにそこにあります。主キーを使用して一意であることを保証できます。気が変わって後でそれが適切でないと判断した場合は、SettingId を簡単に追加して、元の複合キーを一意のインデックスにすることができます。

score 0 · Accepted Answer

1 つの別個の主キーを作成します。ビジネスロジックがどのように変更されても、Key VARCHAR(50) フィールドにどのような新しいルールを適用する必要がありますか? 主キーが 1 つあれば、ビジネスロジックから完全に独立したものになります。

score 0 · Accepted Answer

私の経験では、このテーブルを FK 情報として使用するテーブルの数に依存します。FK を引き継ぐためだけに、他のテーブルに 3 つの余分な列が必要ですか?

個人的には、別の FK 列を作成し、他の 3 つの列に一意の制約を設定します。これにより、このテーブルへの外部キーが飲み込みやすくなります。

sql - SQL: 主キーにするか、主キーにしないか?

8 に答える 8

Related

Reference