RDB のテーブル設計序説
「同じ意味のカラムには同じ名前をつける」は微妙なんだよなあ。created_byはuser_idの一種なのだけど、じゃあusersのidをcreated_byとすべきかってーと絶対マズイわけで。ロール。
2013-12-09 14:39:40あとロールという意味ではusers.user_idじゃなくusers.idとするのは「相対パス」みたいなアレなわけで。それを記述しにくいとしたら言語のほうがショボいという恒例の話になるような。
2013-12-09 14:39:42てか2005年以来(噓)の議論を真似るならば、users.user_idと書くかわりに「優秀なIDEを用意しろ。そうすればusers.idでも問題なくなるぞ」ってことになるはず。
2013-12-09 14:40:56言い換えればドメインを命名規約じゃなく明示的にRDBMSに設定させてくれって話であって、これってポンコツな一部のDBを除けばw既に実装済みなのじゃなかったっけ?
2013-12-09 14:41:56[「値の一部に意味を持たせる」という設計はバッドデザイン]は全面同意。画面とは切り離してDBカラムを(データをぶった切ることで)実現しろとしか言いようがない。
2013-12-09 14:42:56複合キーの問題は複数のテーブル間の疎結合/密結合の問題ともいえる気がしてる。両者にはそれぞれメリットデメリットが有るよという意味でね。
2013-12-09 14:45:06@naka_aki_spl 複合キーというのは、キーというより、ユニーク制約と考えて設計するのが良いかと思うのです。キー(特にプライマリーキー)にはあくまでも、それレコードを一意に識別できる値を保持させる訳です。
2013-12-09 14:52:02@naka_aki_spl で他のキー項目(従来的に考えればプライマリーキーとして扱われていた商品コードとか社員コードも)も、複合キー(アプリケーションへのログイン情報を表わす、時刻 + PC名 + ログインユーザーのアカウントなど)はあくまでもユニーク制約にしておきます。
2013-12-09 14:56:20