質問: 現在構築しているシステムについて ---------------- 採用管理システムを構築しており、以下のようなデータベース構造を検討していました。 * 応募者テーブル [ID][応募日][名前][連絡先]... * 面接予定テーブル [ID][応募者ID][日付][担当者]... その後、どうせなら「面接予定テーブル」を「来客予定テーブル」にしてその他の来客予定も登録し、来客予定全体を管理しようという話になりました。 しかし「その他の来客予定」には関連付ける応募者情報が存在しないことになります。 そのため、以下のようなデータベース構造に変更することにしました。 * 応募者テーブル [ID][応募日][名前][連絡先]... * 面接予定テーブル [ID][応募者ID][予定ID] * 来客予定テーブル [ID][日付][来客種別][担当者]... 疑問点 --- データベース構造については変更後のもので問題ないと考えています。 しかし変更前の構造でも、来客種別の項目を追加して「その他の来客予定」の応募者IDをNULLにすれば、同じようにシステムを構築できるように思います。 それでも構造を変更した方がいいと考えた根拠は、「必ずしも応募者と関連付くわけではないのに、応募者テーブルと紐付いているのが綺麗な構造じゃない」という漠然としたものでした。 そこで質問なのですが、変更前のデータベース構造でシステムを構築した場合、どのような問題・弊害が起こることが考えられるでしょうか。 今までは外部キーで関連付ける情報は必ず存在している状況でシステムを構築しているため、その辺りの経験や知識が不足しているのでよろしければお聞かせください。
回答: もし設計段階でフィールドにNullを含まないことが確定できるのならば、 極力Nullを含まない設計が望ましいと考えます。 (外部キーで縛れるほうがよりいいですね) 例えば、値と比較する場合、SQLは伝統的にNullを対象外とします。 つまり、設計者はそのフィールドを対象に検索したい場合、 値があるのか、あるいは空値なのか、Nullなのか、 3項演算をせねばなりません。 また、取得した結果がNullの場合に、空値として扱いたい場合 変換もせねばならないでしょう。 そうなれば、SQLも煩雑になります。 このフィールドにインデックスを貼りたくなった場合、 パフォーマンスにも影響が出ます。