SQLアタマアカデミー(WEB+DB PRESS vol.47)
今日もネタがないので、本からパクるw
- 作者: 高橋徹,遠藤康裕,はまちや2,正野勇嗣,前坂徹,やまだあきら,笠谷真也,大沢和宏,縣俊貴,ミック,田中洋一郎,有賀一輝,石黒尚久,石室元典,長野雅広,池邉智洋,和田正則,下岡秀幸,伊藤直也,nanto_vi,武者晶紀,大塚知洋,山本陽平,高林哲,小飼弾,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2008/10/23
- メディア: 大型本
- 購入: 10人 クリック: 90回
- この商品を含むブログ (32件) を見る
この本の「SQLアタマアカデミー」の第3回にグレーなテーブル設計が面白かったので、自分的な感想を書いてみようと思う。
■ OTLT(One True Lookup Table) 単一参照テーブル
良く「都道府県コード」「性別コード」「ジャンルコード」見たいに、コードをキーに外部結合して、コードの示す文字列を持ってくるためのマスタテーブルが存在して、コード体系毎にテーブルを用意するわけですが、これが嫌な人は、すべてのコード体系をまとめた、テーブルを設計するよねという話。これを単一参照テーブルと呼ぶらしい。(呼び方は初めて知った。)
図で書くとこんな感じ
code_type | code_value | code_explain |
genre | book | 本 |
genre | tv | テレビ |
pref | 01 | 北海道 |
pref | 02 | 青森 |
sex | 1 | 男性 |
sex | 2 | 女性 |
要はコードの塊を一つのテーブルに持たせて、code_typeを指定して、目的のコード体系を活用しましょうというのが、この方式らしい。けどやっぱり、一つのテーブルが七変化するので、とても自分的には気持ち悪いです。そもそも、普遍的な設定みたいなものを、テーブルに持つこと自体が貴重なDB領域を無駄にしているようであまり好きでなかったりします。
本にも書いてあるとおり、上のような柔軟なテーブル設計にしてしまうと、「code_value」や「code_explain」に入ってる来る値はコード体系によってまちまちなので、カラムのサイズはある程度バッファを持たせないといけないし、カラムのデータ型に関しても、柔軟であるが上に本来INT型の方が望ましいものでも、他のコード体系に併せてVARCHARにしなきゃならんみたいな状況が発生しそうで、あまり効率的でないような気がします。
他にも幾つか、デメリットがありましたが、自分としては、「普遍的?(頻繁に変わらない)なコード体系」に関しては、そもそもDB上で、管理は極力せずにアプリケーション側で設定ファイルか何かで管理する方が、便利なような気がしてます。
- DBに気兼ねする事なくコードが変更できる。
- コード体系の追加・修正が容易である。
- テーブルを余計に用意する必要がなくなる。
みたいなのが嬉しい気がする。ただDBからコード体系を切り離すと、
- DBだけで完結しない。コードが設定ファイルにあるので、値や文字列を持ってくる時はアプリの介在が必要
- コード体系の値をDBに入れるときは、入力チェックをアプリ側でしっかりやる必要がある。
ていう問題も出てくるので、一概に設定ファイルに持つ事がお勧めとは言えないですが、ただOTLTは、あまり宜しくないような気がするので、DBで管理する場合にもコード別にテーブルを作ってあげるのが素直に良いような気がします。
うむ。なんだか落ちがない。けど、本からパクルのはまぁありだな。