IDの設計についてのさらに突っ込んだ議論

今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で

[atsuizo]

「IDはIdentifier（一意識別子）であってcode（符号）ではない」って覚えて意識しておけば良いと思うよ。

[sai5]

一連の議論を読めば読むほど、Rails風の機械的なID採番が（デメリットもあるが）現実的な妥協点としてベターな選択肢であると思えてくる。

[f-shin]

システム都合とユーザビリティ問題のような。電話番号みたいにネットワーク都合もある。連番で確保しておいて、呼び出し用のキーは別に持たせる方が楽。問題はリレーションを張る時に、どっちのキーを信用するか。

[rryu]

結局、真のIDは自然には存在していないので人工的に作り出すしかないという結論に至るのだった。

[caq]

だいたいUUIDを付けることにしてるなあ。変更や移動、抹消や復活とか後から後から要望は出てくるから、全てから切り離されたユニークIDがあるだけでずいぶん安心できる。表示するIDは好きにすりゃ良いと思ってる派。

[atsushifx]

IDというかコードという気がする。学籍番号、郵便番号、電話番号といった昔からのコードは意味づけがあるから管理が大変。Railsとかのサロゲートキーはそのたけの現実的な解。ただし、きちんと正規化しないとあとで問

[shidho]

あれだな、表IDと裏IDだな。裏IDは一意性の保証以外は何もしない。表IDは裏IDから引き出される各種情報を元に結合して作成される。

[chiusagi]

学籍番号を見ればダブりがわかるｗ

[k-holy]

純粋な識別子としてのIDは設計者の脳内にしか存在しない（業務の中に現れることはない）という結論になりそう

[kitokitoki]

“IDの設計についてのさらに突っ込んだ議論”

[Haaaa_N]

RDBにおまかせするのサイコーよね

[areyoukicking]

idにいろんな意味を持たせない

[TTY]

漢(オトコ)のコンピュータ道: IDの設計についてのさらに突っ込んだ議論http://

[potato777]

"IDにはID以外の意味を持たせるべきではない/IDをつけるときは、プライベートな情報を含まないように/種別という属性がなくても番号単体でIDとして機能するようなドメインにすべき"

[naga_sawa]

IDはあくまでも唯一の固有識別子としての存在であるべき/いらん意味を持たせるべきではない/という

[Hayato]

「サロゲート」って言うなっていうはなしなのかなあ？UIのコードとシステム間、テーブル感のコードは違うよって話なのはわかるんだけど。

[hoisjp]

大事 / “漢(オトコ)のコンピュータ道: IDの設計についてのさらに突っ込んだ議論”

[sgtakeru]

IDはずっと変わらず使い続けることができるもの。

[cubed-l]

以前のコメントをそのまま流用。「IDはIDとして使うんだ。意味は持たせない」／DB使うなら意味を持たせる必然性がない

[kazuhooku]

原則論大事

[tinsep19]

今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾る

[BigFatCat]

"番号は種別ごとの連番であって、種別という値がなくなれば意味のないものになってしまう。つまり番号は種別に依存していると言える。そのような単独では意味をなさない属性が存在する意義があるのだろうか？"

[kbkbkbkb1]

IDの設計

[kimutansk]

個人的には「IDがずっと変わらず使い続けることができるか」が一番重要で、それ以外は一段落ちますかね・・・　とはいえ、システム次第ではそれもひっくり返るんでしょうけど

[wtatsuru]

IDにはID以外の意味を持たせるべきではない。

[deg84]

結局どうすればいいのかよく分からない… 連番が無難な気がしてならないんだけどそれじゃダメなんだろうか…

[minamishinji]

興味あり。

[drbomb69]

数値だらけのリレーションが出来ないだろうか…

[issm]

「ずっと変わらず使い続けることができるか」「対象のモノの単位を何にするか」「他のシステムとIDの整合性が取れているか」

[sakidatsumono]

うちの大学も12AB123C方式だなあ

[YaSuYuKi]

一つ前のエントリで☆がたくさんついていたコメントは、この議論を先取りしたようなものが多かったな。/サロゲートキーが悪いのではなく、「代理」でない真のキーになるまで突き詰めないのが悪い

[n-sega]

“より良いIDとは何だろうか。最も重要な基準のひとつとして、IDがずっと変わらず使い続けることができるか”

[m_shige1979]

バージョンに応じて少しずつ変えていくほうがいいかも

[ysync]

まぁ内部ロジックで利用しなければ意味が付いててもいいとは思うけどね。そのID自体が人目に触れるものなら扱いやすさも必要だし。後から被る可能性だけ排除できればいいんじゃね？

[junpeso]

学生が書いたような文章だな。一意性をどのモジュールが確保しなければならないなんて要件に合わせ柔軟に変えればいい。DBが必ず持たなければいけないという理由はない。