すれ違い
いちばんインパクトがあったのが、T字形ER手法はやっぱりサロゲートキーを認めていないとわかったこと。
「コンピュータの内部で勝手に取った連番は、いちばん手に負えない」とのこと。
何が問題かというと「そういうものがあると、組織変更の時とかに大変なことになる」のだそうだ。何で？て話。
で、休憩時間に質問に行ったわけだ。「サロゲートキーがあるとコード体系の変更に強くなるんじゃないんでしょうか」と。
正美氏の答えはこう：
「サロゲートキーは構造の問題を温存する働きをするだな」「サロゲートキーが邪魔になってシステムに実装できなくなる『外界の変化』というものがあるのだな」と。
ダメなコードからはダメな構造しか出てこない。
ダメなコードに別名を付けてみてもダメな構造は変わらない。
構造を変えないと。
http://d.hatena.ne.jp/tgk/20070228#1172679908
うーむ、問題はコードで起こっているんじゃない、構造で起こってるんだ！ ……という主張はわかるのだが、それとサロゲートキーの話がどう繋がるのかよくわからんのだよなぁ。
以前にも書いたが、T字型ERで設計したモデルを誘導的にID付きのモデルにすることは可能なわけで、サロゲートキーにするか否かはモデルの構造とは関係のない話だと思う。その一方、IDを採用することによって実際に企業で発生する「コードの洗い換え」に対応でき、プログラミングや連携機能開発が楽になるというメリットを享受できる（デメリットは、コードからの逆変換ロジック構築のコストがかかるくらいかな？）。
組織変更が大変というのも、よくわからない。最近だと組織や組織階層に適用期間を持たせて対応するのが普通だと思うので、業務系アプリでは問題が起こらないし、会計の残高移行は別の意味で面倒だがコードは関係ない。「サロゲートキーは構造の問題を温存する」という話は前述の通り別の問題だし、「サロゲートキーが邪魔になってシステムに実装できなくなる『外界の変化』というものがあるのだな」ってどういう具体例を指しているのかよくわからない。その一方で、主キーが邪魔になってシステムに実装できなくなる『外界の変化』はよくあったりする（従業員倍増でコードが足りないとか、異なる商品コード体系をひとつのシステム内に入れこまなきゃならんとか）わけだけれど、そこら辺を複合主キーな人はどう考えてるんだろう。
T字型な人に限らずIDに否定的な人が多いのだが、いまだに納得できる否定理由を聞いたことがないのだよなぁ。
