Hatena::ブログ(Diary)

A.R.N [日記]

2006/08/28 (月)

ID or not ID

|  ID or not IDを含むブックマーク  ID or not IDのブックマークコメント

おぉ、ガチだ。

[RDBMS]複合主キー? 18:57
・・・まだそんなこと言ってる人いるのか。
複合主キー? はぶにっき
id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。
関数従属性は多重度に先行して認識される 設計者の発言

いや、お互いものすごく優秀で有名な方だし大人なのでガチの勝負はしてくれないとは思うのだけれど、ぜひ世の多くのさまよえるSEのためにガチンコ勝負して決着つけてくれんかなぁ。てゆうか、今回の案件でもID派(=私)と複合主キー派(=モデラー)でもろに喧嘩してるし、前のプロジェクトでも他の人が同じようなことやってたし、さらに前の案件でも(w そろそろ、IDを使うべきかそうでないかくらいベストプラクティスを決めてほしいなぁと思う今日この頃*1

たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるような場合、いったいいくつ項目持てばいいのかわからないくらい項目が増える場合がある(まぁ大半は設計が悪いだけだったりするのだけど、ID派の立場を取ればそもそもそのような状況はおこらないことを考えれば欠点には違いない)。

個人的には、複合主キーだとマスタに履歴を持つようなケースで変な主キーを選択しなければならなかったり、主キーを更新せざるを得ない場合があって気持ち悪いので、ID派ではあるけど、絶対にIDじゃなければダメだということを説得できるだけの論点が見出せないのが実情。

基本的にトラックバックはしないことにしていたのだけど、恥ずかしながら今日だけはトラックバックを打ってみることにしよう。

*1他力本願でスマソ

habuakihirohabuakihiro 2006/08/28 23:13 あー、どもどもです(^^) TBに反応してみます。
私は、実装できない設計は無意味だと思ってますし、「運用の際に」とか言う以上は、相当に運用経験がないと駄目だと考えています。少なくとも、私は10数年前に自分が実装したシステムのメンテナンスをやりました(転職したのに^^;)し、エンドユーザ企業の運用側にいた上での判断です。プラクティスだけが全てだと考えています。
複合キー派の方には、何か問題があれば全てその人の責任で全部助けてくれ、っていえばいいんじゃないですか。SQLもチューニングしてもらっていいんじゃないでしょうか。当然、そういうアクセスを想定した上での設計なのでしょうから。RDBMSのチューニングが出来ない人間の書いた設計なんて、設計とはいえないでしょう。
我々の仕事は綺麗なモデルを作ることではなく、ユーザのお役に立つシステムをきちんと稼動させることだと、私は考えています。

arnarn 2006/08/29 03:56 つられていただきありがとうございます。

> エンドユーザ企業の運用側にいた上での判断です。プラクティスだけが全てだと考えています。

それはその通りだと思いますが、ということははぶ先生としての結論としては「DB設計をする際にははぶあきひろ(敬称略)を雇え」というのがベストプラクティスということでしょうか(^_^; <いや、それはそれで正しいかも……

「複合キー派の方には、何か問題があれば全てその人の責任で全部助けてくれ」とは言うものの、プロジェクトメンバが自信をもって複合キーにするかしないかを決められるほど優秀で経験豊富ならともかく、私も含めどちらがいいかわからないさまよえる子羊ばかりなのが実情を考えると、メリット・デメリットを考えたときに常にどちらかが良いのであればそちらに乗りたいし、そうでないなら使い分けの基準が知りたいわけです。今のところ私にはその判断がつかないし、開発・運用実績という面では両者とも実際に多く稼動しているわけ(どちらかといえば複合主キーの方が多い?)ことを考えればやっぱり判断がつかないので、はぶ先生と渡辺先生でガチでバトルしていただき、その結論だけいただきたいと(w

> 綺麗なモデルを作ることではなく、ユーザのお役に立つシステムをきちんと稼動させることだと

それには同意します。しかし、複合主キー派はユーザのお役に立つシステムを作るためには綺麗なモデルが必要という主張をしているように見受けられるので批判にはなってないのではないかと。

わたなべわたなべ 2006/08/29 07:03 えへへ、どうなんですかね(^^; はぶさんとはパソコン通信の頃からオンライン、オフラインでさんざん議論してきた仲だったりします。だからもう議論はいいやって感じだし、あえて議論してもarnさんにとって利用しやすい形の「結論」は出ないような気がします。実際、はぶさんの主張は傾聴すべきもので、私もはぶさんの著書をよく読んでいます。結局、勉強と実務を通して各人で判断するしかないと思いますね(^^)

habuakihirohabuakihiro 2006/08/29 07:32 どもども、ご無沙汰しております(^^) > わたなべさん
まぁ、多分みなさんが欲しいのは、議論そのものではなくて結論だと思うのですけど、最終的には自分で選ぶしかないので、我々としてはネタは出し続けます、と。
DB設計担当がいて、その人が方針を出した以上は、その人はそのプロジェクトにおいて全部を背負うしかないんですよ。なので、その人が背負える形でしかやれないとは思いますです。

arnarn 2006/08/29 12:29 はぶ先生、渡辺先生ありがとうございます。

すでに散々議論した結果結論がでないということはモデラーが責任持つ以外にはないんでしょうね。

> 多分みなさんが欲しいのは、議論そのものではなくて結論だと思うので
議論そのものにも興味はあるのですが、IDにするか複合主キーにするかって別に業務要件で決まるわけでもなくある意味プロジェクトとしてはどうでも良い部分なのに毎度もめて時間的にも感情的にももったいない気もして、なんだかなぁと思っていたものでして。

どこの会社もどこの会社も 2006/08/29 14:37 >毎度もめて
もめますね(w
結局複合主キーにしたほうがあとあとわかりやすいからという理由で、
複合主キーになりました。
ほんとどっちでもシステム構築できるんだから、
もめたくないなーって感じですね。

わたなべわたなべ 2006/08/29 19:13 はぶさん、おひさしぶりです。いろいろと勉強させていただいています。ありがとうございます。ガチンコで議論することはもうないと思いますが、それぞれの世界で地道にネタ出しを続けてゆきましょうかね(^^)

arnさん。
> 毎度もめて時間的にも感情的にももったいない気もして、なんだかなぁと思っていたものでして。
わかるなあ、その気持ち。同じようなことで毎回言い合うなんてバカバカしいことこのうえないですよね。うまくガイドできない先輩としては恥じ入るばかりです。

HATHAT 2006/09/01 04:07 渡辺さんのブログから流れて来て、羽生さんのブログも読みました。面白い場を提供していただきありがとうございます。
ここに「主キーなんていらない」というT字形(TM)の方がいらっしゃれば、また深い議論になりそうです。議論にすらならないか(笑)
現実問題としては、洗い替えの大変さの度合いを見越して複合キーにするかサロゲートキーを導入するかを判断してるように思います。履歴とかログとかには主キー属性をつけない事も多いですね(RDBMS次第ですけど)。
何でもサロゲートキーにするって方法は考え方として簡単ですけど、私には割り切りすぎているように思えます。こういう部分の悩みというか試行錯誤でお客様の業務をより深く理解出来て良いシステムになるってことがありますから。一発で素晴らしいモデルを書ける方にとっては簡単な方がいいのでしょうね。

arnarn 2006/09/01 23:59 HATさん、こんにちわ。

> こういう部分の悩みというか試行錯誤でお客様の業務をより深く理解出来て良いシステムになる
うーん、それには同意できないなぁ。アセンブラで書けばJavaよりも試行錯誤するから良いシステムができあがるか、ってそんなことはないですし。むしろ、どうでもいいことで悩む時間を別のことに使いたいかも。

> 一発で素晴らしいモデルを書ける方にとっては簡単な方がいいのでしょうね
私はID派なのではぶ先生を擁護するのですが(w その時にはどんなに素晴らしいモデルであっても、業務要件が日々変化する可能性がある以上、変化に強いシステム=ID派モデルというのは運用まで考えたとき、その意義がはっきりとしてくるのではないでしょうか。とはいえ、どう考えたってこの会社変わらねーよなぁという場合もあるので、強くは主張できないのですが。

HATHAT 2006/09/02 01:57 arnさん、レスありがとう。

>どうでもいいことで悩む時間を
 どうでも良くないから悩むのですけどね。例えば楽々フレームワークっていう製品だと、フレームワークが勝手にサロゲートキーをとってくれたりします。これはこれで便利そうなのですが、今話題にしてるのは実装じゃなくてデータモデルなんですよね?

 概念モデルの時には主キーは意識しない方が自由な発想が出来ますが、論理モデルのリレーションシップを考える時には主キーをベースにしないと、実業務と乖離したモデルを作ってしまいがちです。私のような凡人がお客様の業務と真正面から向き合うためには、安易に流れない方が良いという経験則です。

 最高のパフォーマンスが必要ならT字形だってのはわかってるのですが、実際に使った経験はありません。一度使いたいけど。

arnarn 2006/09/02 11:10 やっぱりこの話題は熱くなりますね(^_^)

> 今話題にしてるのは実装じゃなくてデータモデルなんですよね?
私はそうは思えないのですよ。T字型で作ったものは誘導的にID式にすることができますから、モデル自体には関係ないんじゃないかなぁ。どちらかと言えば、実装技術といいますか。

ID派の考え方は、主キーの持つポインタとしての役割とリレーションの候補キーとしての役割をわけろと言っているだけなので、論理モデル設計の際にHATさんの言われるようなことは当然行うのだと思います(ABDでもするのかは知らないけど)。

> 最高のパフォーマンスが必要ならT字形
今のプロジェクトで使ってますが、結構いまいちかも。
技術的な面での良さは感じるのですが、プロジェクト管理という面でみると、メンバのモデルに対する理解がまちまちになるT字型はよくないかもなぁーと。最初から物理モデルで見せないと、具体的なSQLが頭に浮かばないので、よーわからんという反応が起こってきます。パフォーマンス(=データベースの速度)とかシステム間連携とかが考慮されにくいので、本当に実装まで落とせるかも不安ですし(モデラーの力量の問題もあるのかもしれないけど)。

HATHAT 2006/09/02 20:59  今、T字形を実務で使われてるのですか!それは貴重な体験かと

 佐藤正美さん自身がRDBMSの設計者側からこの世界に入った方なので、技術者にはSQLの完璧な使いこなしを求める手法だと思ってます。「joinが遅い」という経験が刷り込まれてる技術者(私もそうですが)には使いこなせないと感じて手を出してません。でも魅力的ではあります。

 書籍を読んだあとで佐藤さんにお会いして何度か尋ねたことがあります。
「DBMS側で許されるなら主キーは設定しないで下さい」とか「騙されたと思ってそのまま実装して下さい」と言われました。でも「T字形命」とイレズミしてるような優秀な技術者と話してると、微妙にくずすことで従来の技術者でも受け入れやすくしてるようでした。こういう方々はT字形として守るべき一点が明確なのでそれ以外がどれだけ崩れても気にされないようでした。

>言われるようなことは当然行うのだと思います

 羽生さんのブログを読んだだけでは、複合キーが出てきた瞬間に何も考えずサロゲートキーをつけてしまうように読めたのです。もし安易に流されず論理モデル設計をされてるなら私の読み間違いです。すみません。

 もし羽生さんのデータモデルが実装技術なのでしたら、あまり議論する気がありません。使用するフレームワークで使いやすいように実装すればいいだけだからです。

戯音戯音 2006/09/21 07:17 こんにちわ。
自然キーでの結合って「ゆるやかな結合」「よわい結合」「動的な結合」という感じである気がするのは俺だけでしょうか?どっかの言語でいうWeakRefみたいな感じぃ?人工キーでの結合は、ある時点で自然キーなりなんなりで(その場で)得られた関連付けを「永続化」「固定化」する手段に使える感じ?

arnarn 2006/09/21 09:05 戯音さんこんにちわ。
> 自然キーでの結合って「ゆるやかな結合」「よわい結合」「動的な結合」という感じである気がする

そういう面はあるでしょうね。ただ、以下の二点から業務アプリではそのような考え方は必要ないと考えます。
・業務アプリにおけるトランザクションは事実の記載であるので、動的に結合されると困る(実際、複合主キーだと結合が動的になりやすいが故にトランザクションに名称などをコピーすることが多いですよね)
・設計から離れ実装フェイズに入ると、画面間のデータ引渡しのためIDが必要な場面が非常に多い(Webの場合特に)。この場合動的な結合だとデータを引き渡してる間に結合が変化してエラーになってしまう場合があるが、そのような状況を想定しつつプログラムを書くのは非常に困難

戯音戯音 2006/09/24 14:48 「業務アプリ」という特定分野においてはということでしょうか。色々な用途に横断的に使うぞ!っていうDBだと微妙だってことでしょうか。

あれ?「引き渡してる間に結合が変化してエラー」ってのはID方式でも(対象行が消されたら)起きることだったりしませんか?

arnarn 2006/09/24 17:31 > 「業務アプリ」という特定分野においてはということでしょうか
Yes。というよりT-ERやオブジェクト指向設計も含め対象業務があったのデータベース設計なので業務アプリでないものまで適用することは余り考えてないです。組み込みだったらDBなんて使わないし、人工知能用データベースでどういうテーブル設計をすべきかなんて想像がつきませんので(^_^;

> ID方式でも(対象行が消されたら)起きることだったりしませんか?
ID方式なら(IDが使いまわされない限り)その情報が削除されたことが確実です(すなわち、結合自体は変化していない)が、複合主キーだとキーに含まれる情報が変更されただけかもしれませんし、(同時期に主キーが変更され)運悪くまったく別の行がヒットしてしまうかもしれません。まぁ、主キーが変更されるような設計はするなという話ですが、トランザクション系のデータではわりと起こりますよね。

個人的には、業務アプリにおいてはデータは削除してはいけないのではないかと思ってはおりますが(業務的には削除してよい場合でも、導入後のバグ発見の際に有用)。

戯音戯音 2006/09/25 12:01 CADデータ管理ソフトや、世間の謎のWebサイト(^^;なんかでも、同じ原則でやれるのかな?ってのが気になってます。蛇足ですが組み込みかどうかとDBと業務ジャンルはそれぞれ互いに直交ですよね…

>主キーが変更されるような設計

主キー洗い出しスキルの甘さ(^^;に対するFoolProofとしてもID方式は有用そうですね。後で体系が変わって慌てることを回避できる。逆にいえば下手設計の温床にならなければ良いのですが。

といってもID方式は、意味的な主キーっぽいものからIDへのマッピングを設計時に行う(実行時にDB上には持たない)に行うのだと思いますが、そこで既に間違えていたらグダグダになりますね。(まあ駄目設計でグダグダになるのは意味的な主キーをそのままDBで使う場合も同じですが。定量的には被害量が大きいのかな?)

結局、それぞれの案件において「なにが「ひとつ」なのですか?」という問いに対してキチンとした答えが出せるようになってないと、どっちにせよDBなんて設計しちゃいかんのでしょうね。なんだ、OOPも同じじゃん(^^;

>削除してはいけない

個人的には「データ特定はID一発でいけるようにしろ」「過去データ全部残せ。更新は新リビジョンの登録で実現せよ」っていうXanaduみたいな(^^;方式は好きですし、「業務」云々じゃなく基本的に全てのジャンルで適用していいと思っています。人的コミュニケーションにすら有効ではないかと思っています。その思想の延長としてかつて某Wikiに履歴機能をつけてもらったりもしましたし…。

そういう意味ではデータ設計より下の「インフラ」的に捉えてます。そしてそれの存在を前提としてデータも設計すりゃいいんだろなと。RDBというインフラ(^^;を前提としたDB設計が有りなら、ID&履歴というインフラを前提としたDB設計も有りだと思います。RDB+ID/履歴管理FWという(はぶさんの(ですよね))主張はそういう意味で賛同です。

ただこれはあくまで個人的好みでしかないので、工学的ないしは現場的な有効性はよく判ってないです。

蛇足ですがバージョン付けはCVS方式(行単位で新版に採番する)かSubversion方式(コミット単位で採番する)かドチラがいいかな?と少々悩んでます。まあ時刻にしちまうのが簡単だろうとは思うのですが…

戯音戯音 2006/10/06 13:59 IDって、データに対するPermalinkなのかな…

arnarn 2006/10/08 01:02 > IDって、データに対するPermalinkなのかな…
なるほど、Permalinkとは良い説明かも。マシン名+ドメイン名+DB名+スキーマ名+テーブル名+IDで世界中で一意に特定できますもんね。

トラックバック - http://d.hatena.ne.jp/arn/20060828