[pgsql-jp: 31227] テーブルの構造について

[Chie.M]

Chieと申します。お世話になっております。

テーブルを作成していて、迷った事がありまして
ご相談させていただきます。

例えば、従業員管理のテーブルがあったとします。
このテーブルには従業員の名前や生年月日などユニークな情報を
入れるテーブルになっています。

このような場合、従業員に紐付けされるユニークのデータであれば、
一つのテーブルとして扱うのが普通だと思います。

この時、このテーブルに必要なの情報が沢山あって、
一つのテーブルにすると、カラムが200とか300とかになったとします。

このテーブルはすごく良く使うテーブルなのですが、
頻繁に使うカラムは、数百カラムのうち10カラム程度だったとします。

それ以外のデータは必要ではあるのですが、滅多に使用しません。
また空欄である場合もかなりあります。

ここから質問なのですが、このような場合、考え方として
下記の２つのどちらがよいのでしょうか？
（他の案もあれば教えてください）

・全てを一つのテーブルとしておく
・良く使うカラムとそうでないカラムをわけて、複数のテーブルとし、
　それを1対1の関係で紐付けるようにして使用する。

良く使うテーブルなのに、あまり使わないデータがある大きなテーブル
というのは、なんとなく重くなりそうな気がしてます。
一方で、一意の情報を別々のテーブルにわけてしまうというのは
冗長になるというか、構造的によくないような気もしてます。

ちなみに、私の場合は、今までは、
関連づけられる情報ごとにまとめたテーブルを複数作っていて、
主になるテーブル（従業員の名前が入っているようなマスターテーブル）
と1対1でそれぞれを紐付けて使用していました。

例えば、
・従業員名や部署IDなどが入っている、頻繁に使うテーブル
・住所や電話番号、最寄駅や定期代などが入っているテーブル
・緊急連絡先などが入っているテーブル
・社会保険番号や雇用保険などの保険関係のテーブル
・・・
などのような感じです。

しかし、このような考え方でいくとテーブルがドンドン増えて
いってしまう上、使いにくくなるような気もしてきました。

私はPHPを使っているのですが、たまに使うテーブルのために
ビューとルールを作っておいて更新処理などをかけたりすると
pg_affected_rows()で件数の取得ができなかったりしますし。
もちろん、PHPでの処理の仕方を変えればいいだけなんですが
ちょっと不便なかんじです。

皆様が開発されるときは、こういう場合はどのように
考えますでしょうか？

参考までに是非教えていただけると幸いです。
よろしくお願いします。

-- 
Chie <gontakun_72 ＠ yahoo.co.jp>