[B! DB] IDの設計についてのさらに突っ込んだ議論

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

2013/12/10 リンク

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

2013/12/10 リンク

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

2013/12/10 リンク

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

データベース

2013/12/10 リンク

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

2013/12/10 リンク

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

2013/12/10 リンク

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

2013/12/10 リンク

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

プログラマ

2013/12/10 リンク

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

2013/12/10 リンク

規約違反を報告

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

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