タグ付けされた質問 「surrogate-key」

代理キー/人工キーの一般的な利点の1つを理解しています。変更されないため、非常に便利です。これは、「人工」である限り、単一フィールドでも複数フィールドでも同じです。 ただし、各テーブルの主キーとして自動インクリメント整数フィールドを持つことはポリシーの問題のように思われる場合があります。これは常にそのような単一フィールドのキーを持っているのが最良のアイデアですか？なぜですか？ 明確にするために、この質問は人工対自然に関するものではなく、すべての人工キーを単一フィールドにする必要があるかどうかに関するものです

33 database-design  primary-key  surrogate-key 

私はサロゲートキーのファンです。私の発見が確認バイアスのリスクがある。 こことhttp://stackoverflow.comの両方で見た多くの質問では、IDENTITY()値に基づく代理キーの代わりに自然キーを使用しています。 コンピューターシステムの私のバックグラウンドは、整数の比較演算を実行すると、文字列を比較するよりも高速になることを教えてくれます。 このコメントは私の信念に疑問を投げかけたので、整数はSQL Serverのキーとして使用する文字列よりも高速であるという仮説を調査するシステムを作成すると思いました。 小さなデータセットでは識別可能な差はほとんどないため、プライマリテーブルに1,000,000行、セカンダリテーブルにプライマリテーブルの各行に10行、合計で10,000,000行の2つのテーブル設定を考えました。二次テーブル。私のテストの前提は、このような2つのテーブルセットを作成することです。1つは自然キーを使用し、もう1つは整数キーを使用し、次のような簡単なクエリでタイミングテストを実行します。 SELECT * FROM Table1 INNER JOIN Table2 ON Table1.Key = Table2.Key; 以下は、テストベッドとして作成したコードです。 USE Master; IF (SELECT COUNT(database_id) FROM sys.databases d WHERE d.name = 'NaturalKeyTest') = 1 BEGIN ALTER DATABASE NaturalKeyTest SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE NaturalKeyTest; END GO CREATE DATABASE NaturalKeyTest ON …

25 sql-server  sql-server-2012  performance-testing  surrogate-key  natural-key 

テーブル間の外部キーを自然キーまたはサロゲートキーにリンクするかどうかのベストプラクティスはありますか？私が本当に見つけた唯一の議論は（私のgoogle-fuが欠けていない限り）この質問でのJack Douglasの答えです。私はルールが変わるということを超えた議論を知っていますが、これはどんな状況でも考慮する必要があるものです。 尋ねる主な理由は、自然キーを持つFKを使用するレガシーアプリケーションがあることですが、開発者からOR / M（この場合はNHibernate）に移行する強いプッシュがあり、フォークは既にいくつかを生成していることです変更を壊すので、自然キーを使用して変更を元に戻すか、FKのサロゲートキーを使用するようにレガシーアプリを移動します。私の腸は元のFKを復元すると言っていますが、これが本当に正しい道かどうかは正直わかりません。 テーブルの大部分には、既に一意キーとPKが定義された代理キーと自然キーの両方が既に定義されているため、このインスタンスでは余分な列を追加する必要はありません。SQL Server 2008を使用していますが、これがすべてのDBに十分な汎用性を持っていることを願っています。

14 database-design  foreign-key  surrogate-key  natural-key