9

IDを作成して保存するためのベストプラクティスは何であるか疑問に思いました。数年前、教授は、社会保障番号を例として使用して、不十分に構築されたIDシステムの危険性について私に話しました。特に、SSNにはエラー検出機能がないため、9桁の文字列と有効なSSNの違いを区別することはできません。そして今、政府機関は、データを追跡し、その検証を確実にするために、姓+SSNや誕生日+SSNなどを必要としています。さらに、あなたの社会保障番号は、あなたが生まれた場所に基づいてある程度予測可能です。

今、私はユーザーデータベースを構築しています...そしてこのアドバイスに基づいて、「useridmediumintauto_increment」は受け入れられないでしょう。特に、このIDをユーザーのプライマリIDとして使用する予定の場合。（たとえば、ユーザーにユーザー名の変更を許可した場合、ユーザー名は数値のユーザーIDよりも追跡が難しくなります...カスケード外部キーなどが必要になります。）電子メールの変更、ユーザー名の変更、パスワードの変更。 。ただし、ユーザーIDは永久に一定である必要があります。

明らかに、auto_incrementはsurrogate_keys用にのみ設計されています。つまり、プライマリ識別メカニズムがすでにある場合にのみ便利なショートカットですが、データの「固有の識別子」として使用しないでください。ランダムなUUIDを作成することは面白そうに見えますが、ランダム性は私をオフにします。

そして、私は尋ねます：「主キー」識別番号を作成するためのベストプラクティスは何ですか？

4

7 に答える 7

10

内部データベース機能と外部検索条件を混同しています。

自動インクリメントサロゲートキーは、内部アプリケーションでの使用に役立ちます。それらをユーザーに渡さないでください。ユーザーであろうと請求書であろうと、ビジネスオブジェクトの識別は、SSN、CCN、DOBなどのオブジェクトに関する一意の情報を使用して行われます。オブジェクトを一意に識別するために、必要なだけの情報を使用してください。

新しく発明されたID値を各顧客に提供する必要がある場合は、それがすべての顧客データテーブルをリンクするフィールドではないことを強くお勧めします。

于 2010-12-03T23:14:22.603 に答える
3

ベストプラクティスは、自動インクリメント整数を使用することです。「固有の識別子」として使用すべきではないという本当の理由はありません。これは、外部キーで最もコンパクトな使用法と最速の検索を提供します。他のほとんどの値は変更される可能性があり、キーとしての使用には不適切です。

于 2010-12-03T22:33:32.873 に答える
1

SSNを自動インクリメントされた整数と比較するのは、リンゴとオレンジです。個人的には、テーブルに非常に多くのレコードがあり、整数を使用するのが非効率的または不合理になる場合を除いて、GUID / UUID/UIDを避けています。

真の自然キーが見つかることは非常にまれです。今日ユニークと思われるものは、ビジネス要件/法律に基づいて明日変更される可能性があります。

于 2010-12-03T22:39:36.740 に答える
1

上記のコメントでの会話に基づいて、私はこれを回答として投稿しています。ランダムで一意のIDをユーザーに割り当てると、通常の認証方法を使用せずに十分なセキュリティがユーザーに提供されると信じているようです。

とにかく、保護されたデータと、ユーザーテーブルの自動インクリメントの整数ベースのID列との比較に混乱しています。これらの2つのタイプのデータが混ざってはいけません。クレジットカード会社は、データベーステーブルの主キーとしてCCNを使用するべきではありません。また、政府は、データベーステーブルの主キーとしてあなたの名前またはSSNを使用するべきではありません。

なぜあなた（または誰か）は、いくつかの保護されたデータの知識だけでユーザーを認証する必要がありますか？企業はSSNに基づいてユーザーを認証することができなくなり、クレジットカード会社がCCNに基づいて私を識別しないことを知っています（特に、複数のアカウントがあり、アカウントのカード番号が数回変更されているため） ）。

UUIDを実装して任意の乱数を生成したとしても、それはそれだけです：数値。Active Directory認証では、IDにGUIDが使用されますが、ユーザーはユーザー名とパスワードを入力する必要があります。ID列としてより大きなまたはより小さなデータ型を使用することは、他の種類の認証またはセキュリティの手を洗うことができるという意味ではありません。

于 2010-12-03T23:03:43.933 に答える
1

IDを公開するために他のデータベースが何をするかを確認するのに役立つかもしれません。

Salesforceは、最初の3文字を使用してオブジェクトを判別し、次の12文字では大文字と小文字が区別されます。

したがって、Salesforceアカウントは001で始まり、Salesforce連絡先は003で始まります。

したがって、Salesforceアカウントでは、大文字と小文字が区別される15桁の001000246abcABCのようになります。ただし、大文字と小文字を区別するIDはExcelの問題（並べ替え、重複排除など）であるため、ほとんどの人は大文字と小文字を区別しないSalesforceの18桁のIDを使用します。それらを15から18に変換するための標準的な式があります。

Stripeは、IDの前に顧客の場合はcus_、支払いの場合はpi_を付けます。したがって、顧客はcus_abcdABCD123456（14桁）である可能性がありますが、支払いはpi_0123456789abcdeABCDE1234（24桁）である可能性があります。

Xero IDは、連絡先abcd1234-ab12-12ab-9902-abcdef123456では次のようになります。

QuickBooks Onlineは、IDを会社固有の増分整数として公開するという疑わしい決定を下しました。したがって、請求書は1、2、3などになります。これは、すべてのQBO会社の請求書IDが1であるという点でも問題があり、複数のQBO会社のデータが1か所にある場合はデータベースでの衝突が避けられません。

于 2021-08-22T17:28:23.273 に答える
0

結局のところ、特定のユーザーの識別子が有効かどうかを確認する方法は、システム自体です。つまり、システムはこれらの識別子の信頼できるソースです。555-45-9999は有効なSSNですか？確実に知る唯一の方法は、社会保障にそれを調べさせ、その番号を持っていると主張する人の名前と一致させることです。もちろん、SSN識別子スキームを使用して、それが有効かどうかについて予備的な推測を行うことができます。ただし、システムを検索するだけで確実にわかります。チェックディジットの必要性は、たとえば、他の人があなたのシステムによって尊重される番号を生成できるようにしたい場合がある高度に分散されたシステムで発生します（たとえば、顧客が独自の追跡番号を生成できるようにする運送会社）。自動化された方法で識別子を生成するのはシステムなので、

于 2010-12-03T22:48:43.120 に答える
0

これは、解決するように設計されたシーケンスです。挿入ごとにアトミックに増やすことができるオブジェクトを作成します。自動インクリメントされた整数であるDBと、シーケンスオブジェクトであるDBもありますが、考え方は同じです。つまり、競合することなく一意のキーを作成します。

また、IDとしてのUUIDは問題なく、特別な理由で以前に使用したことがあります。なぜランダム性は「あなたをオフにする」のですか？競合の可能性は事実上ありません。

于 2010-12-03T22:41:44.750 に答える