ナチュラルキーでもいいじゃない・・・
あぁ、そういえばこんなブログ書いてたな･･･
何か、4年も前の日記に最近謎のトラックバックがあったようで、ってか、まだログインできたんだこのブログ。凄いな、はてなさん。
前の日記の時代から既に転職しちゃってますけどね。あはは、若かったなぁ僕。
ってか、続きはまた今度で終わってるなぁ。もう忘れてるけど。ひたすらレジストリを手作業消去して廻って解決しました。お礼に缶コーヒー貰いました。おいしかった筈です。ちゃんちゃん。
仕事でＤＢに関係することでちょっとやらかし・・・気になったことがあったので色々調べていたら、ナチュラルキーvsサロゲートキー論争の記事に出くわしまして。見てて面白かったので。
【用語注釈】
●ナチュラルキー：
業務に直接使用されるデータ（社員ID、顧客IDなど）をテーブルの主キーとする場合の呼称
●サロゲートキー：
プログラム管理上で利用する、業務には直結しないデータ（連番値、ランダム値）をテーブルの主キーとする場合の呼称
【それぞれの特徴】
●ナチュラルキー：
実際に使用する値を軸にテーブル関係を見ることが出来、業務とテーブルの関連が直感的に理解し易い。テーブルの親子関係を明示し易く、この場合複合キーが用いられる。但し、データの連鎖性に優れる余り、仕様変更による影響も甚大で、複合キーも多すぎるとSQL文が冗長になりがち。
●サロゲートキー：
業務に関係無いデータをキーとする為、業務改善等によるデータ仕様の変更に強く、単一のキーで管理される為、テーブル結合処理が楽。但し、どのテーブルがどのテーブルに事実上影響しているのかが解かりづらく、SQL文もサブクエリが多くなりがちな為、人を相手にした可読性は劣る。
【でもって、判り易い論争の現状】
ナチュラルキー派：パッと見判り易くていいじゃねーか
サロゲートキー派：仕様変更し易くていいじゃねーか
う〜んなんとなく、ネット上ではサロゲートキー派が多いかなって感じですね。ってか最近の趣向って感じ。やっぱ仕様変更はついてまわるものですからねぇ……
……でも不思議なのは「じゃあ仕様変更が発生しなかったらナチュラルキーの方がいいってことじゃん！」って声高らかに言ってる人がいないことですね。多分言ったらアホだと思われるからでしょうね。
僕はアホなので構わないですが。
ただ実際問題、システムが10年間稼動しました。その間に何度も仕様変更がありました。でも、ナチュラルキーとなる部分の仕様変更は一切ありませんでした。
・・・となった時、初回設計時にナチュラルキーという手法を選択した人に対して「お前は間違っていた！」とは断言できないと思うんですよねぇ。10年もあれば、その間に先方もこちらも担当者が変わっているわけで、この場合解かり易さのメリットの方がシステム可用性のメリットより大きかったってことにならないかなぁ。まあ「未来のことなんか解かるか！」って言われりゃそれまでだけど。
あ、でも「あの時の俺にはこの未来が見えていたんだよ！」って言い切ったらカッコいいね。カッコいいだけだけど。
まあ、どっちにも一長一短あるってのは確かなので、「俺は時と場合とシステム規模によりけりだな派」っていう、曖昧模糊としたコウモリ的な意見の人がもうちょっといてもいい気もする。
……ってか、大概の二元論って「要は一長一短」って言葉で片付く気がするんだけど……
