RDB のテーブル設計序説

@naka_aki_spl がぼやいてたのを受けて、ちょろっと書いた。この分野は業務エンジニアなら真剣にやったことがあるはず(私も相当悩んで大きくなった w)。もっと沢山書きたいことあるので、それの超手抜きイントロ・ヴァージョン。続きはどこかに書けよ > 俺。お前ふたつツイートしただけだろうという突っ込みは却下!!!
1
非実在naka aki @naka_aki_spl

「同じ意味のカラムには同じ名前をつける」は微妙なんだよなあ。created_byはuser_idの一種なのだけど、じゃあusersのidをcreated_byとすべきかってーと絶対マズイわけで。ロール。

2013-12-09 14:39:40
非実在naka aki @naka_aki_spl

あとロールという意味ではusers.user_idじゃなくusers.idとするのは「相対パス」みたいなアレなわけで。それを記述しにくいとしたら言語のほうがショボいという恒例の話になるような。

2013-12-09 14:39:42
非実在naka aki @naka_aki_spl

てか2005年以来(噓)の議論を真似るならば、users.user_idと書くかわりに「優秀なIDEを用意しろ。そうすればusers.idでも問題なくなるぞ」ってことになるはず。

2013-12-09 14:40:56
非実在naka aki @naka_aki_spl

言い換えればドメインを命名規約じゃなく明示的にRDBMSに設定させてくれって話であって、これってポンコツな一部のDBを除けばw既に実装済みなのじゃなかったっけ?

2013-12-09 14:41:56
非実在naka aki @naka_aki_spl

[「値の一部に意味を持たせる」という設計はバッドデザイン]は全面同意。画面とは切り離してDBカラムを(データをぶった切ることで)実現しろとしか言いようがない。

2013-12-09 14:42:56
非実在naka aki @naka_aki_spl

複合キーの問題は複数のテーブル間の疎結合/密結合の問題ともいえる気がしてる。両者にはそれぞれメリットデメリットが有るよという意味でね。

2013-12-09 14:45:06
Yasunori Taniike @ytaniike

@naka_aki_spl 複合キーというのは、キーというより、ユニーク制約と考えて設計するのが良いかと思うのです。キー(特にプライマリーキー)にはあくまでも、それレコードを一意に識別できる値を保持させる訳です。

2013-12-09 14:52:02
Yasunori Taniike @ytaniike

@naka_aki_spl で他のキー項目(従来的に考えればプライマリーキーとして扱われていた商品コードとか社員コードも)も、複合キー(アプリケーションへのログイン情報を表わす、時刻 + PC名 + ログインユーザーのアカウントなど)はあくまでもユニーク制約にしておきます。

2013-12-09 14:56:20
Yasunori Taniike @ytaniike

今のは纏めといて、後でちゃんと書いてもよいなぁ。

2013-12-09 14:57:49