SQLアタマアカデミー(WEB+DB PRESS vol.47)

今日もネタがないので、本からパクるw

WEB+DB PRESS Vol.47

WEB+DB PRESS Vol.47

この本の「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で管理する場合にもコード別にテーブルを作ってあげるのが素直に良いような気がします。

うむ。なんだか落ちがない。けど、本からパクルのはまぁありだな。