A.R.N [日記]

■[開発] ID付与は設計技法ではなく実装技法

なのではないかと主張してみるテスト。

ここではぶ先生に否定されてしまうと、私は第三勢力アクシズとして動かなければならんのですが、男のハマーンはいやですか（←いやです）

論拠は二つ。

どのようなモデルでも誘導的にID方式に変更できる

はぶ先生がidとはROWIDのことだ、と言っているように単にRDBMS上にオブジェクトモデルと相似の構造（ポインタによるリレーション）を作るだけなんだから、当たり前の話ではある。複合主キー派の方は、全部サロゲートキーにするなんて！ という反応を見せるわけだけど、ID派の言うIDとサロゲートキーは似て非なるものなのだと思う。旧来の主キーの役割はユニークキーが担うだけの話なわけだし。T-ERで論理モデルを作成した後に、IDを主キーにして作って、参照先をIDにするようにモデルを修正するだけでT-ER的に正しくなおかつID方式のモデルが出来上がる。モデリング技法によらないならば、これは設計技法ではなく実装技法であるということになる。

モデリングが楽にならない

はぶ先生自身が複合主キーだと「ERDがちょびっと見やすくなる」とかID付与だと「実装や運用が楽になる」と言っていることからわかるように、ID付与はモデリングにはまったく役立たない。ようするにID付与はモデリング手法ではなく、プログラムやモデルの変更強度や実運用性を強したり、プログラミングを楽にするための手法、すなわち実装技法であると言える。

ただ、そう考えると何でDOAの人がID導入に否定的なのかよくわからんのだよなぁ。

[参考]

http://d.hatena.ne.jp/habuakihiro/20060903#1157251646

http://d.hatena.ne.jp/habuakihiro/20060829#1156819448

ツイートする

■[開発] なぜ私はID派なのか

今までいっしょに仕事した人とこの話題については結構話したけど、プログラマはID派に好意的（確実に開発は楽になるし、オブジェクト指向との相性もいいので理解しやすいし、変更にも強いわけだから当然と言えば当然）。逆にばりばりのモデラーは理解できないというような顔をすることが多い。開発よりの運用の人は変更に強いID派に当然好意的、オペレータよりの運用はテーブルの中身を見るのにいちいちJoinしなければならないのはめんどくさい、あるいはスキルが低いなどの理由で複合主キー派の方がいいみたい。

私の場合、前職ではいくつかのシステムで要件定義から運用までやって経験から言えば、ID付与方式の方がよいと思っていたし、はぶ先生の本を読む前に同じ結論に至っていたりする（ちょっと自慢）。

とは言っても、前職はとあるグループ企業の情報システム部門みたいな会社で、とんでもなく仕様変更の多いグループだったので例外的かも。三ヶ月に一回くらい組織構造が変わるは、突然従来と異なる組織階層ができあがるは、数年で社員数が倍増するは、兼務の数も半端じゃないうえ異動も激しいし（兼務が激しいと同じ人が複数の違うグループ会社で役職をもっていて、ひとつのシステム内で全部の情報をいっぺんに見たいみたいな要望もでてきたりする）。そういう場所だと、ID方式じゃないと結構死ねます。「二週間後に社員コード体系(数値→英数＋桁数アップ)が変わるんで対応よろしく」とか。実際にはすべてのシステムが複合主キー方式だったので担当者は結構死んでました(w

というわけで、とてつもなく仕様変更の激しい企業ではID方式をお勧めします(ww

問題は成熟した企業なら複合主キーの方がわかりやすいだろうなぁ、と思うこともあり強くは主張できるほど立場が固まってないのが現状なので、いろんな人の意見を読んで頭の中を整理中ではあるのですが。

ツイートする

■ガチでやらない

と言っていたのに、やってるなぁ。うーむ、私が煽った格好になってしまいました。

なんだか申し訳ない気分。

ツイートする