代理キーをユーザーに公開する必要がありますか？

多くの場合、自然キーを持たないテーブルでは、ユーザーが一意に生成された識別子を保持できると便利です。テーブルに代理主キーがある場合（そして、そのような場合は必ず期待します）、そのキーをユーザーに公開する必要がありますか、その目的で別のフィールドを使用する必要がありますか？

サロゲートキーを公開しない理由の1つは、レコード間の関係を保持する操作を実行できないが、特定の種類の削除/再挿入、1つのデータベースからデータをコピーする多くの方法など、キー値を変更することです他など

代理キーを公開する主な利点は、とにかく持っているフィールドを簡単に使用できることです。

どのような状況で、代理キーをユーザーに直接公開する方がよいでしょうか？

変更が必要なユーザー/顧客に公開される識別子の準備ができている必要があります。また、データベース内の行のIDを変更し、その変更をすべての外部キーに伝播することは、データを破壊することを要求するだけです。

データに自然なビジネスキーがない場合は、「ビジネス識別子」のフィールドを追加できます。これは、使用されるプロセスに対して最適化する必要があります。電話のキーパッド入力は数字のみを意味します。電話/口頭では、同様の音のシンボル（B / D、M / Nなど）を避けます。覚えやすいフレーズ（「グリーンゼリー」）を自動生成することもできます。

これの効果は、ビジネスが後でレコードを参照する方法を変更できることであり、唯一のデータスキーマの変更は、そのスタイルのIDに新しい列を追加するか、既にそこにあるIDを変換することです。変更はデータベース全体に反映されず、時間の経過とともに有効なID（サロゲート）がまだ1つあります。

つまり、サロゲートキーをユーザーに公開することは避けます。コメントが指摘しているように、代理キーはほとんど変更されません。逆に、企業はすべてを変えたいと思っています。代理キーが公開されている場合、ビジネスがそれを変更するのは時間の問題です。

補足として、ここで「公開する」と言うときは、キーを直接使用することを期待してユーザーにキーを提供することを意味します（注文番号でサポートに電話するなど）。

場合によっては、代理キーが期待され、ユーザーにとって意味があります。私のお気に入りの例は「注文番号」です。注文番号は実際には自然なキーではありません。自然なキーはタイムスタンプにユーザーを加えたものかもしれません。

それでも、ユーザーは注文番号の利便性を理解し、期待しています。ユーザーに通知しても、害はなく、多くの価値があります。

一方、一部の代理キーはユーザーにとって意味がありません。確かに、私の健康保険会社には、メンバーID、生年月日、キャリアなどに基づいて私を識別するいくつかの代理キーがありますが、それについては気にしません。私の雇用主であり、宇宙全体で一意ではありません...したがって、保険会社の代理キー）。

適切に生成されたGUID / UUID *である場合にのみ、代理キーを公開する必要があります。OWASPのトップ10のセキュリティ問題では、連続した代理キーを公開するのが4です。

*実際には、暗号で保護されたランダムまたは擬似乱数ジェネレーターによって作成されたことがわかっていない限り、これらの目的のために適切に生成されなかったと想定するのが最善です。

テーブルに自然キーがない場合、代理キーはこのような行を許可します。

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

代理キーではなく、これらの人工キーと呼びますが、この質問ではその区別は重要ではありません。

ここで、外部キーを介してこれらの代理キーを参照する重要なデータがあると仮定すると、エンドユーザーは代理キーの値を知らない場合、どの行を更新するかをどのように知るでしょうか？

素人の言葉で：

• サロゲートはユーザーに対して非表示にする必要があります。
• 他のビジネス候補キーをユーザーに公開する必要があります。
• 他の候補キーが存在しない場合は、PKを表示する必要があります。ただし、この場合、PKは他の列の代替ではないため、サロゲートとは見なされません。

ユーザーに有用な情報を提供するフィールドを直接またはユーザーに報告する際にのみフィールドを公開する必要があります。

逆に、ユーザーが実行する対話のレコード（単純または複雑）を識別する主な手段である場合は、常に「代理主キー」を公開する必要があります。

キーをエンドユーザーに公開するかどうかは問題ではありません。アプリケーションは、たとえば注文IDを知るだけでは、通常はアクセスできないものへのアクセスを許可できないように、必要な承認を実行する必要があります。

警告：これは、サーバー側の認証が可能な/実行可能なWebベースまたはn層のアプリケーションを想定しています。sqlを直接実行するVBアプリがある場合、それはまったく別の問題です。