リレーショナルデータベースが自然キー（サロゲートキーではない）を使用して設計されているときに、データベースの問題の種類は何ですか？

Question

このコメントを見ました：

[アプリケーション]ほとんどのデータ関連の問題は自然キーを使用したものでした。

出典：Surrogate vs. natural/business keys

コメントは想像にあまりを残したように私は、こののより多くの支持証拠が欲しいです。

自然キーを使用することでデータに関連する問題が発生することが示唆されていますが、何がうまくいかないのか...データは破損しますか？同期外れ？間違った、紛失した、傷ついた？質問するのは難しいですか？

サロゲートキーの使用に反対するナチュラルキーを使用してデータベースを設計した場合に発生するデータの問題は何ですか？サロゲートキーを使用しているとき、どのようにして問題の種類を防ぐことができますか？

Answer 1

ナチュラルキーの主な問題は、関連するテーブルにどのように影響するかです。キーの値を変更する場合は、元の値を参照するすべての行をすべての表で修正する必要があります。

たとえば、郵便番号または郵便番号の表があるとします。多くの場合、これらは郵便番号が自然の鍵となる場所で設計されています。郵便局が特定の郵便番号を変更したとします（92680は92780になります）。郵便番号表のキーを変更するときは、その郵便番号を参照するすべての表に移動し、そこで更新する必要があります。したがって、郵便番号の92680を持つ顧客アドレス、ベンダーアドレスなどの各行は、92780に変更する必要があります。

明らかに、関連するテーブルが修復されていない場合、大きな問題が発生する可能性があります。郵便番号に基づいて保険料を請求するとします。これらがプレミアムテーブルで修正されていない場合に起こりうる問題を想像してみてください。

代理キーを使用すると、この問題は完全に排除されます。郵便番号表の郵便番号を変更するだけです。サロゲートキーは変更されません。また、関連するテーブルには代理キーが格納されているため、他のものを変更する必要はありません。