データベースの設計について

朝からデータベースの設計について悩んでいます。

テーブルにしたいデータがあるのですが、
それぞれカテゴリーが違うデータがあります。

構造的には少ししか違わないのですが、
これらのデータを1つのテーブルとしてまとめるか、
それとも、それぞれ1つずつのテーブルにするか迷っています。

迷っている理由として：
・同時にアクセスがあった場合、全て一つのテーブルにまとめていると、障害がないか？
・全てを1つのテーブルにすると、多少は構造が違うので、必要のないフィールドが出てしまう。

それぞれを1つのテーブルで分割するということも考えたのですが、
例えば、全てのデータからある特定のデータの検索をかける場合に
不都合なのではないか？と考えてしまいます。
こういう場合には：
select * from table_A where field="検索したいデータ";
select * from table_B where field="検索したいデータ";
select * from table_C where field="検索したいデータ";
とテーブルの分だけSQLを実行するしかないのでしょうか？

どちらを選択しても、それぞれ一長一短のようで、混乱しています。

よろしくお願いします。

No.1 ベストアンサー 回答者： Te-Sho 回答日時： 2005/07/20 15:40

候補としては４つぐらいあるでしょうか？

１）すべて別テーブル
２）１つのテーブルで固有項目を全て別の列で持つ
３）１つのテーブルで固有項目を固有項目１～として持ち、取り出してから加工
４）共通項目を１つの親レコードのテーブルとして持ち、固有項目を子レコードとして複数テーブル持つ。

おなじ意味合いの項目を検索すると言うことがあるようですから１）は無しですね。

ちょっとMySQLの仕様がわからないので微妙なんですが可変長な文字列（OracleでいうVARCHAR2など）データが格納されていないときに、あまり容量を取らない方であれば２）でもあまり問題ないかと思います。

３）の場合は容量は取りませんが固有項目に何が入っているか取り出したあとに型変換が必要になる可能性もあります。

私なら４）で共通の親テーブルと固有カラムごとの子テーブルを作ります。

共通の横断検索を行うときは親テーブルのみを検索するだけですし、データベースの拡張、固有項目や共通項目のカラム追加時のシステム影響度も少ないです。
システム構成の変更時もトラブルが少ないと思います。
ただし親と子を同時に更新する必要がある場合はトランザクション処理の考慮が必要です。

No.2 回答者： moon_night 回答日時： 2005/07/21 11:51

あまり具体的ではないので、的確な回答はできませんが、

例えば、
テーブル１が
ユーザーID|ユーザー名|データ１|データ２
で
テーブル２が
ユーザーID|ユーザー名|データ１|データ３|データ４

くらいの違いならば
リレーションを考えて
テーブル１
ユーザーID|ユーザー名
テーブル２
ユーザーID|データ１|データ２
テーブル３
ユーザーID|データ１|データ３|データ４

としたほうがすっきりするのではないかと思います。

取り出す場合は

select * from テーブル１ left join テーブル２ on テーブル１.ユーザーID = テーブル２.ユーザーID;
のようにすればいいかと思います。
（やり方によっては3つや4つのテーブルを結合させることもできます）