ナチュラルキーに変更があると大変
ナチュラルキーは業務データをキーにするものである
業務データは、変更されうる
ユニークであることを担保しつつも、変更することができる
swapすることもできる
主キーの値が変更されると、更新しなければいけないものが増える
そのtable自体はもちろん、relationが張られているtable全てに影響する
例えば、Scrapboxで言えば、project内の「ノートのタイトル(title)」を例にするとわかりやすい
titleはproject内で一意なので、notes tableの主キーに採用しようと思えばできる
しかし、
titleを主キーにしている場合
table:notes
title(主キー) contents
ナチュラルキーを採用しない 主キーの設計には、...
ナチュラルキー ナチュラルキーとは、..
table:relate_notes
title related_title
ナチュラルキーを採用しない ナチュラルキー
ナチュラルキーを採用しない 主キー
ナチュラルキーを採用しない DBの設計
..
ここで、「ナチュラルキーを採用しない」という値が変更された場合、notesもrelate_noteも全部更新しないといけない
人工的なデータを主キーにしている場合
table:notes
note_id(主キー) title contents
1 ナチュラルキーを採用しない 主キーの設計には、...
2 ナチュラルキー ナチュラルキーとは、..
table:relate_notes
note_id related_note_id
1 2
1 3
1 4
titleを変更した場合、notesの中の1つの値を修正すれば済む
単一キーであっても、サロゲートキーを含めるべき、とも言える
要は、ビジネスとは関連のないサロゲートなキーを導入すべきという主張をしている
その値が一つでユニークであったしても、それがビジネスと関連している場合、ビジネス側で仕様変更があると影響がでかい
例えば、社員を識別する社員コードがあれば、社員を一意に特定できるが、これはユーザーにも見えている値で、業務に関連する値である
そのため、これはビジネス要件として修正される可能性がある
だから、こういう場合でもこれとは別にサロゲートキーを導入したほうが良い、という主張とも言える