from ナチュラルキーがある時はサロゲートキーは不要

ナチュラルキーは業務データをキーにするものである

業務データは、変更されうる

ユニークであることを担保しつつも、変更することができる

swapすることもできる

主キーの値が変更されると、更新しなければいけないものが増える

そのtable自体はもちろん、relationが張られているtable全てに影響する

例えば、Scrapboxで言えば、project内の「ノートのタイトル( title )」を例にするとわかりやすい

title はproject内で一意なので、notes tableの主キーに採用しようと思えばできる

しかし、

titleを主キーにしている場合

ここで、「ナチュラルキーを採用しない」という値が変更された場合、notesもrelate_noteも全部更新しないといけない

人工的なデータを主キーにしている場合

titleを変更した場合、notesの中の1つの値を修正すれば済む

サロゲートキー v.s. 複合主キーでは、前者を選ぶでの議論は、何も複合主キーを使っていることに起因するものでもない

単一キーであっても、サロゲートキーを含めるべき、とも言える

要は、ビジネスとは関連のないサロゲートなキーを導入すべきという主張をしている

その値が一つでユニークであったしても、それがビジネスと関連している場合、ビジネス側で仕様変更があると影響がでかい

例えば、社員を識別する社員コードがあれば、社員を一意に特定できるが、これはユーザーにも見えている値で、業務に関連する値である

そのため、これはビジネス要件として修正される可能性がある

だから、こういう場合でもこれとは別にサロゲートキーを導入したほうが良い、という主張とも言える