delete＆insert するデータのIDを維持しなくてはならない ... のだろうか (2)
前回
http://d.hatena.ne.jp/tgk/20060913#1158169167
の続き。
いろいろコメントをいただいたおかげで理解が進んだ。がっつり整理する。
IDあるいは代理キーの導入に肯定的な人であっても、立場がいろいろある。今見えているポジションが３つ。
- 全てのテーブルにidという名前の主キー列を
- 必ずしも付けない
- 個体識別されているデータのみに付ける -- (1)代理キー派
- 必ず付ける
- 今誰も見ていない、delete＆insertするデータのIDを
- 維持する。あるいはdelete＆insertという実装方法を禁じ手にする -- (2)ID維持派
- 維持しない -- (3)ID更新派
- 今誰も見ていない、delete＆insertするデータのIDを
- 必ずしも付けない
私自身は現状では代理キー派に近い*1。ID派に宗旨替えしたいのだが、ID維持派・ID更新派のどちらが正しいのか分からない。
ID維持派・ID更新派の気分になって考えると、それぞれもっともな感じがする。
ID維持派なら：
IDが今たまたま外部キーになっていなくても、将来外部キー参照されるかもしれないから、更新の度にIDが変わるように作っておくのはまずい。
「コードではなくIDが外部キーになることによって、データ構造が安定する」というのがIDの売りのひとつなのだから。
とすれば、delete＆insertという実装方法を禁じ手にするか、delete＆insertするにしても、IDを維持するように実装するのが正しい*2。
ID更新派なら：
IDは *レコードの* ライフサイクルの表現と、一意性の保障をするためものだから、delete＆insertしてIDが変わってしまうのは別におかしなことではない。
むしろ今必要ではないことにコストを払う方がおかしい（IDを維持するように実装する追加コストは、大したことはないとしても、ゼロではない）。
更新の度に変わるIDを外部キーにすることはできないので、このIDは将来的にも外部キー参照されることはない。
だからあっても無駄だとも言えるが、いちいちIDをつけるかどうか考えるコストがもったいないから、無駄でもつけておけばよい。
「全てのテーブルにidという名前の主キー列を付ける」というやり方を実践された方は、ID維持派・ID更新派のどちらの考え方を取ったか（あるいは「このフレームワークを使ったら自動的にこっちになった」とか）教えていただけるとすごいありがたいです。
