顧客テーブルの主キーとして個人番号を使用するのは良い考えですか？
私たちは、自社で顧客を処理するための新しいシステムを設計しています。私と別の開発者は、顧客の個人番号を主キーとして使用する必要があるかどうかに分かれています。私の好みは、新しい顧客ごとに一意のID（int）を自動インクリメントすることです。
現在、私たちが追加するすべての顧客には個人番号がありますが、これが良い実装または悪い実装である理由の良い例はありますか？
引数の1つは、増分IDを使用すると、不要なフィールドが追加されてより多くのスペースを占めることになるということです。
個人番号はvarcharとして格納され、customerテーブルには100万人近くの顧客が保持されます。個人番号またはIDは、注文およびカスタマーサポートリクエストの外部キーとして追加されます。
これらが良い実装か悪い実装かをどうやって知るのですか？どのように私はどちらの側を主張しますか？
キーを選択または設計するためのいくつかの良い基準は次のとおりです。シンプル、安定性、および親しみやすさですが、最初に、キーが対処することになっている基本的なビジネス要件を理解する必要があります。ビジネスプロセスで顧客をどのように特定するつもりかを自問してください。あなたが顧客を特定する要件があり、顧客番号があなたのビジネスがそれを行うために使用する手段であると仮定すると、それは顧客テーブルのキーとして完全に理にかなっています-必ずしもonlyキーではありませんが、確かに- aそのテーブルのキー。
私たちがBIの世界で行うことは、すべてを維持することですNatural Keysソースシステムから、同時にDB生成ID（Surrogate Key）。この用語では、個人番号はNKになります。この数を変更した場合、または変更した場合に、追跡可能性と変更の追跡を可能にするために保持します。すべての履歴/ソースシステムIDを保持しながら、ソリューションで新しく効率的なPKを有効にします。
結合のパフォーマンス向上、クエリの単純化、およびDBの一貫性のために、増分する整数を使用します。 IDを制御すると、一意性と、いつどのように割り当てるかを保証できます。外部から提供されたIDでは、潜在的な変更や衝突を制御できません。
スペースの問題はないと思います。 100万の8バイト整数を標準のディスクサイズ（テラバイトなど）で格納するために必要なスペースの概算でさえ、重要ではありません。
あなたが説明しているのは一般に悪い習慣です。あなたは数字にダッシュを言及しますが、数字が何であるかについては言及しません。それは社会保障番号や電話番号に沿ったものだと思います。
社会保障番号の場合、この番号の使用にはプライバシーの問題がある可能性があります。配置されている外部キー制約を破棄せずに、セキュリティ上の目的で番号をマスクすることはできません。
電話番号の場合、誰かの電話番号が変わったり、複数の電話番号を持っている場合はどうなりますか？ （つまり、彼らはあなたに彼らの仕事番号を与えましたが、今は彼らの細胞を使いたいと思っています）。
外部データベース（電話帳、税務記録など）を通じて数を決定できるため、これらの両方にも懸念があります。
これらのエンティティの主キーには、自動インクリメントIDを使用することをお勧めします。これをクラスター化インデックスのキーとして使用すると、ランダムに挿入する必要がなく、新しいエンティティがテーブルの最後に追加されるため、断片化が少ないという利点があります。