1

既存の列の使用を回避できる場合に、PK に ID 列を使用することが正しい方法であるかどうかを判断するために、私はまだ戦っています。

例：

CREATE TABLE person_link
(
     person_link_id INT NOT NULL IDENTITY(1,1)
    ,owner_person_id INT NOT NULL
    ,link_person_id INT NOT NULL
    ,link_date_created DATETIME NOT NULL DEFAULT(GETDATE())
    ,deleted_person_id INT NULL

     CONSTRAINT pk_person_link PRIMARY KEY(person_link_id)
    ,CONSTRAINT fk_person_link_owner FOREIGN KEY (owner_person_id) REFERENCES person (person_id)
    ,CONSTRAINT fk_person_link_link FOREIGN KEY (link_person_id) REFERENCES person (person_id)
)

または、person_link_id を削除し、常に一意になる 2 つの列に主キーを配置する必要があります。すなわち:

CONSTRAINT pk_person_link PRIMARY KEY(owner_person_id, link_person_id)

それは単なる個人的な選択ですか、それともアイデンティティを使用しない正当な理由がありますか (純粋に、私は常に使用しているため、私は賛成です)。

4

3 に答える 3

3

ID列をクラスター化インデックスとして使用する利点は、すべての挿入が最後のレコードになるため、SQLServerがインデックスを再利用する必要がないことです。

結合する場合にも利点があります。子テーブルに1つの参照があれば十分です。

追加するデータまたはデータベーススキーマ（他の場所でこれを使用する必要がある場合）によっては、これらは関連しない場合があります。

于 2012-08-16T01:25:56.733 に答える
2

私は ID 列を好みます。繰り返しますが、何かがオンになっている正確な行を見つけることが役立つことがわかりました。

たとえば、テーブルに追加された最新の行を見つけるために、私はほとんど直感的に次のクエリを作成します。

select t.*
from t
order by 1 desc

私は常にIDをテーブルの最初の列にしているので、これはうまくいきます。

さらに、テーブルで結合を行うときに、主キーを単一のフィールドにすると役立ちます。特定のエンティティを識別したい場合、特定のエンティティ ID を持つことに勝るものはありません。

于 2012-08-16T01:17:10.507 に答える
2

必要に応じて、私は個人的にレコードに自然な主キーを使用するので、2 つの列は常に一意になります。

したがって、テーブルは次のようになります。

table:
owner_person_id int -- PK
link_person_id int -- PK

ただし、実際には、テーブルの計画と、どのオプションを選択するかのデータベース設計によって異なります。

于 2012-08-16T01:17:16.020 に答える