質問: テーブル設計に関して判断に迷ってしまったので、ご意見を伺いたいです。 前提として、基本情報を登録するための親テーブルがあり、それに紐づく任意の数の予定を登録できる子テーブルがあります。 今回、それとは別に種別の異なる予定を登録できるようにする必要が生じました。 現在のところ、予定の登録内容として必要な項目は既存の子テーブルと完全に一致しています。 このような場合、同じ構造の別のテーブルを作るべきでしょうか。 それとも種別の違いを区分値として、既存のテーブルにカラム追加するのみの変更とするのがよいでしょうか。 最初は種別が異なるデータを同じテーブルにするべきでないように思えたのですが、 今回の場合はそれぞれの種別で項目が追加になる可能性はほとんどないので、同じテーブルで区分値で分けてもよいのではと考えているのですが、いかがでしょうか。
回答: 例えば予定を検索する際に、`予定`と`別の予定`を同時に検索するような状況があり得るか検討してください。単純なWHEREでの検索だけでなく、別のテーブルとの結合や参照制約なども含まれます。 あり得るのであれば、1つのテーブルにするべきです。 単純な例では、1つのテーブルであれば ``` SELECT * FROM `予定` WHERE ... ``` ですむことが、`別の予定`テーブルを作ってしまうとできなくなります。 逆にこのような状況がないと言い切れるのであれば、1テーブルにまとめてはいけません。 > > 「1テーブルにまとめてはいけません」と言い切る理由が知りたいと思いました > > > 実務的には、例えばこのテーブルに関わるすべてのクエリに条件指定が必須でこれを漏らすとバグになる、という問題があります。 DB設計の大原則みたいな話ですし、DBでなくとも「異なる種類のものを1つにまとめる」のがよくないのは自明なことだと思います。 DBはプログラムの都合で考えるとたいていよくないことが起きるので、DBを扱うのであればDB設計委の基本は身につけておいた方がいいと思います。