sql-server - GUID と自動インクリメント整数の両方を使用する

Question

データベースの主キーとしての GUID の使用を調査してきました。これまでのところ、長所が短所を上回っているようです。ただし、GUID が必要なものではない可能性がある点が 1 つあります。

私のアプリケーションでは、ユーザーはわかりやすい ID に基づいてオブジェクトを識別できる必要があります。したがって、たとえば、フルネームを入力せずに特定の製品を入手したい場合は、製品の ID を使用できます。そのような場合、GUID を覚えるのは簡単ではありません。

私が考えてきた解決策は、GUID と自動インクリメント整数の両方を使用することです。GUID は行の主キーになり、自動インクリメント整数はアプリケーションのフィルタリング関数で使用されるインデックスになります。ただし、すべての SQL SELECT、UPDATE、DELETE ステートメントは GUID を使用します。

GUID を使用する主な理由は、2 つのデータベースをマージする際の衝突を防ぐためです。データベース #1 とデータベース #2 の両方に製品 #2 がある場合、インポーター スクリプトは ID とそれを参照するすべての外部キーを変更する必要があります。GUID を使用すると、テーブル自体のわかりやすい ID を変更するだけで済みますが、外部キーはインポートされた各レコードに固有の GUID を使用するため、変更しなくても機能します。

それで、私の質問は次のとおりです。自動インクリメント整数インデックスと GUID プライマリ キーを持つことで、(GUID フィールドのサイズと簡単なページの断片化以外に) 大きな問題はありますか?

Answer 1

私は常に、データベースで代理主キーを使用する傾向があります。つまり、これらの主キーは問題のドメインでは実際の意味を持たないため、これらの主キーがユーザーに公開されることはありません。(この代理主キーのタイプが GUID または ID である場合、私は気にしません。これは要件によって異なります)。

ユーザーが使いやすい ID に基づいてオブジェクトを識別できるようにする必要があると言う場合、この使いやすい ID は「問題のドメイン」に属する値であると思います。つまり、この ID は実際にはテーブルの属性である必要がありますが、テーブルの主キーとして使用するべきではありません。

これにより、関連する外部キーの変更についても心配することなく、ユーザーフレンドリーな ID の値を簡単に変更することができます (必要な場合)。

Answer 2

「なぜ「ユーザーは使いやすい ID に基づいてオブジェクトを識別できる必要がある」のですか?

私の意見では、ユーザーはコードを使用してレコードを識別すべきです。

データベースに製品が含まれているとしましょう（質問で言及したように）。ユーザーが入力できる、製品を表すコードがあればもっといいのではないでしょうか。

あなたがテーブルと椅子を持っているとしましょう。ユーザーとして、私が話していることを識別するために 1 と 2 よりも tbl と chr を使用したいと思います。

Answer 3

あなたの質問についてより具体的に言うと、はい、データベースの主キーとしてGUIDを使用することには他の問題があります。

http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx

問題は、主キーとしてGUIDを使用することではなく、テーブルのクラスター化インデックスとして非順次GUIDを使用することです。

ここでのポイントは、クラスター化されたインデックスとして他のフィールドを使用するか、この断片化を回避するためにシーケンシャルGUIDを使用することです。

Answer 4

ではMySQL、数値を として設定する必要IDがあります。PRIMARY KEYAUTO_INCREMENTPRIMARY KEYNOT NULL

テーブルはではなく数値でクラスター化されますがUNIQUE INDEX、列に を定義しGUIDてどこでも使用できます。InnoDBidGUID

Answer 5

サロゲート ID を外部の世界に公開してはならないという考え方があります。そのため、ビジネス ID が必要な場合は、別のものを使用する必要があると言うでしょう。

たとえば、このウィキペディアの記事には、次のように書かれています。

解離

生成された代理キーの値は、生成されて任意であるため、行に保持されているデータの実際の意味とは関係ありません。サロゲート キーへの外部キー参照を保持している別の行を検査する場合、行自体のデータを調べただけでは、その参照を保持している意味を理解することはできません。データ項目を理解しようとする際にナビゲートする必要がある外部キー結合ごとに、この間接化にレイヤーが追加されます。これにより、不正なデータが検査で明らかにならないため、監査がより困難になる可能性もあります。

また、代理キーは、エクスポートおよび共有されるデータには不自然です。特に難しいのは、スキーマの 2 つのインスタンスが、論理的には同じことを意味する (つまり、ビジネス上の意味では同じである) レコードを保持できますが、キーがどのように割り当てられたかの履歴のために異なるキーを持つ可能性があることです。これに対処するためのアプローチは、代理キーがエクスポートまたはインポートされないというルールを採用することです: 一時的なデータとして (最も明白なのは、データベースへの「ライブ」接続を持つアプリケーションを実行する場合を除いて) 代理キーはデータベースの外部に公開されることはありません。