代理キーまたはaccountnoフィールドを主キーとして使用する
私は、ファイナンシャルアドバイザー向けのシンプルなポートフォリオ管理システムを設計しています。ここの中央のテーブルは、アドバイザーが管理するさまざまなアカウントを保持する「tb_account」テーブルです。ランダムな一意のアカウント番号を作成し、それをテーブルtb_accountの「accountno」フィールドに格納します。フィールドは、テーブルの主キーでもあります。現在、アカウント（別名ポートフォリオ）に関する詳細情報が格納されている他のテーブルがあります。これらのテーブルはすべて「accountno」によって駆動されます。
私が持っている質問は、「accountno」をtb_accountテーブルにのみ格納し、それに一意のインデックスを作成し、他のすべてのテーブルで「id」というテーブルの代理主キーを使用する必要があるかどうかです。
こちらに両方のデザインの画像があります。どちらのルートに行けるか教えてください。両方の長所と短所も役立ちます。メインのtb_accountテーブルを除くすべてのテーブルから「accountno」フィールドを完全に非表示にできるため、後者に傾いています。しかし、テーブル間の結合が推奨されない、または不可能である可能性がある「マイクロサービス」ルートに進むことを選択した場合、そのような設計は妨げになりますか？.
2番目のアプローチを使用します。アカウント番号などの情報を主キーとして使用する場合の問題は、理論的には変更できることです（はい、クライアントが今言っても、変更されることはありません）。データベース行を一意に識別するidフィールドをそのまま使用します。
優れたPKには3つのプロパティがあります最低でも：
- それは一意です。（新しいIDを生成するための十分な「スペース」。）
- 小さいです（たとえば、
varcharとは異なります。） - 安定していて独立しています。（レコードに関する情報をエンコードまたは導出しません。）
状況によっては、他の要件が存在する場合があります。たとえば、一部のデータベースエンジンは昇順のPKを使用することで大きなメリットを得ます。これは、ディスクのレコードをPKで（少なくともデフォルトでは）並べ替えるためです。テーブルの最後にレコードを追加する方が、予測できない場所に挿入するよりもかなり高速です。
ただし、ここにもビジネス上の考慮事項があります。
- はい：顧客または利害関係者が画面に表示するものはすべて、彼らです。
- ただし、アカウント番号が変更可能な場合、監査要件はskyrocketになります。
これら2つの事柄は、潜在的に互いに対立しています。 （しかし、おそらくあなたが思うほど頻繁ではありません。）そして、ビジネスにとってより重要なものを整理する必要があります—監査能力の重要性と監査をどのように実行するか口座番号が変更可能な場合
顧客または詐欺師がアカウント番号で電話をかける場合、必ずする必要がありますデータベース内の何かを参照してください。顧客がドキュメント（ステートメント、請求書など）に関する質問で電話をかけるとき、そのドキュメントのアカウント番号は常にデータベースのアカウントと一致する必要があります。
番号が変更されたアカウントに不正な未払いの注文がある場合、注文に使用されたアカウント番号を顧客に知らせることができます。 その他
そしてもちろん、実際の監査人があなたの記録を掘り起こしているとき、紙の記録が一致しない場合、彼らは満足しませんデジタルのもの！
これで、PKとアカウント番号を個別に持つことができます。両方とも固有のフィールドです。たぶん、1つは醜いUUIDで、もう1つはナイスな短いcharです。ただし、どちらか一方を変更することを変更することをお勧めしますと仮定して、これらのフィールドを分離しないでください。どちらも不変である必要があります。 （お客様向けのアカウント番号は、PK、IMOよりもさらに重要です...）