3

I have read a lot of articles about whether we should have primary keys that are identity columns, but I'm still confused.

There are advantages of making columns are identity as it would give better performance in joins and provides data consistency. But there is a major drawback associated with identity ,i.e.When INSERT statement fails, still the IDENTITY value increases If a transaction is rolled back, the new IDENTITY column value isn't rolled back, so we end up with gaps in sequencing. I can use GUIDs (by using NEWSEQUENTIALID) but it reduces performance.

4

4 に答える 4

8

Gaps should not matter: the identity column is internal and not for end user usage or recognition.

GUIDs will kill performance, even sequential ones, because of the 16 byte width.

An identity column should be chosen to respect the physical implementation after modelling your data and working out what your natural keys are. That is, the chosen natural key is the logical key but you choose a surrogate key (identity) because you know how the engine works.

Or you use an ORM and let the client tail wag the database dog...

于 2009-11-12T08:07:20.593 に答える
4

すべての実用的な目的のために、整数は主キーに理想的であり、自動インクリメントはそれらを生成するのに最適な方法です。PK が無意味 (代理) である限り、それは顧客の創造性から保護され、その主な目的 (テーブル内の行を識別する) に十分に役立ちます。インデックスはパックされ、結合が高速になり、テーブルを簡単に分割できます。
GUID が必要になったとしても、それで問題ありません。ただし、自動インクリメント整数を最初に考えてください。

于 2009-11-12T13:00:14.103 に答える
1

それはあなたのニーズに依存すると言いたいです。多くの Sql Server インスタンスを持つ分散システムを開発しているため、主キーとして Guid のみを使用します (デフォルトは NewID に設定されています)。ただし、Guid 列を PK として使用する場合は、クラスター化インデックスとして使用しないでください(リンクの marc_s に感謝します)。

ガイドタイプの利点:

  • 同期せずに異なる場所に一意の値を作成できます

不利益：

  • データ型が大きく (16 バイト)、さらに多くのスペースが必要です。
  • インデックスの断片化を作成します (少なくとも newid() 関数を使用する場合)

主キーは定義上一意でなければならないため、データの一貫性はデータ型に依存しない主キーの問題ではありません。

ID 列の結合パフォーマンスが優れているとは思いません。結局のところ、パフォーマンスは適切なインデックスの問題です。主キーはインデックスではなく制約です。

ギャップのない typ int の主キーが必要ですか? 通常、これは問題になりません。

于 2009-11-12T08:13:28.023 に答える
0

「はい、パフォーマンスが低下します。完全に。 SQLServerテーブルのクラスタリングインデックスはBADBADBAD-periodであるため、」

本当かもしれませんが、これによると、GUIDPERSEも悪い悪い悪いと結論付ける論理的な理由はわかりません。

たぶん、そのようなデータに他のタイプのインデックスを使用することを検討する必要があります。また、dbmsでいくつかのタイプのインデックスから選択できない場合は、より優れたdbmsを取得することを検討する必要があります。

于 2009-11-12T18:47:06.773 に答える