Q&A
回答ありがとうございます。
NULLという特殊な値を持ってしまうことで、空値を含む本来の型の値とは異なる挙動を常に意識ないといけなくなる、ということですね。
回答を見て「NULLではなく空値にすれば大丈夫では？」とも考えたのですが、
その場合は外部結合を行うと照合先の部分がNULLとなり、他の問題は解決できても「取得後の値を変換する」という問題は残りますね。
逆に考えれば、結合は空値でないものしか行わず、結果にNULLが含まれなければ変更前の構造でも問題ないでしょうか？
現在構築しているシステムについて
採用管理システムを構築しており、以下のようなデータベース構造を検討していました。
- 応募者テーブル
[ID][応募日][名前][連絡先]...
- 面接予定テーブル
[ID][応募者ID][日付][担当者]...
その後、どうせなら「面接予定テーブル」を「来客予定テーブル」にしてその他の来客予定も登録し、来客予定全体を管理しようという話になりました。
しかし「その他の来客予定」には関連付ける応募者情報が存在しないことになります。
そのため、以下のようなデータベース構造に変更することにしました。
- 応募者テーブル
[ID][応募日][名前][連絡先]...
- 面接予定テーブル
[ID][応募者ID][予定ID]
- 来客予定テーブル
[ID][日付][来客種別][担当者]...
疑問点
データベース構造については変更後のもので問題ないと考えています。
しかし変更前の構造でも、来客種別の項目を追加して「その他の来客予定」の応募者IDをNULLにすれば、同じようにシステムを構築できるように思います。
それでも構造を変更した方がいいと考えた根拠は、「必ずしも応募者と関連付くわけではないのに、応募者テーブルと紐付いているのが綺麗な構造じゃない」という漠然としたものでした。
そこで質問なのですが、変更前のデータベース構造でシステムを構築した場合、どのような問題・弊害が起こることが考えられるでしょうか。
今までは外部キーで関連付ける情報は必ず存在している状況でシステムを構築しているため、その辺りの経験や知識が不足しているのでよろしければお聞かせください。
回答4件
0
RDBの世界ではNULLは邪悪な存在と考える方も多いようです。
私はORMを通してRDBを使う事がほとんどなので、あまり気にしなくてもORMが適当にやってくれるので「NULLダメ!絶対!!!」とまでは思わないのですが、極力避けられるところは避けるように気にかけてはいます。
なんでダメなんだー?? という話は
NULL撲滅委員会 がおもしろかったです。
同じ方が書かれている3値論理 ―― 神のいない論理 も非常に勉強になりました。
投稿2016/10/21 22:46
総合スコア1728
0
ベストアンサー
もし設計段階でフィールドにNullを含まないことが確定できるのならば、
極力Nullを含まない設計が望ましいと考えます。
（外部キーで縛れるほうがよりいいですね）
例えば、値と比較する場合、SQLは伝統的にNullを対象外とします。
つまり、設計者はそのフィールドを対象に検索したい場合、
値があるのか、あるいは空値なのか、Nullなのか、
3項演算をせねばなりません。
また、取得した結果がNullの場合に、空値として扱いたい場合
変換もせねばならないでしょう。
そうなれば、SQLも煩雑になります。
このフィールドにインデックスを貼りたくなった場合、
パフォーマンスにも影響が出ます。
投稿2016/10/21 14:12
総合スコア716
>逆に考えれば、結合は空値でないものしか行わず、
>結果にNULLが含まれなければ変更前の構造でも問題ないでしょうか？
そのあたりは一般論を用いるべきではなく、実設計で柔軟に対応するべきでしょう。
ただ、自身の経験則から言えば、Null入らない予定だけど、
別に縛ることもないからNull許可しとけ、なんてフィールドには
大抵、（自分を含めた不用意な）誰かがNullを入れてしまうものなのです・・・。(><｡
確かに、設計時は「空値でないものしか結合しないから大丈夫」と思って作っても、時間が経ってから見た時に「結合先が存在しないけど大丈夫か？」とか考えたりもしそうですね…
事前に防止できるなら、防止するに越したことはないと思います。
大変参考になりました。
ありがとうございました。
0
外部キーがNULLでないこと--- の意味解釈がDBエンジンに任せ、人依存でない場合、と
--- DBエンジンには任せず運用担当者がルールを守り場合、と
の２通りでそれぞれの功罪をよーく考える必要があります。
一方が良くて他方が悪いと常に言うことがあれば幸せですが、現実には「システムで対応できないので、肉体労働を強いられて周囲や肩書の上位の人から不興を買う」こと覚悟できないこともあるかと思います。
投稿2016/10/25 09:55
総合スコア65
回答ありがとうございます。
システム側でNULLを生まないような仕組みにしておくか、NULLを生まないような使い方を利用者に求めるか、というお話でしょうか？
システム側と利用者側、それぞれにどこまでを求めるかの線引きは難しいところですね。
私も作業効率化のためにとシステム化した結果、そもそも処理しなければいけない仕事量が増えてしまった、という事もありました。
システム側に求めるのか、利用者側に求めるのか、それぞれの場合にどのような影響があるのか。設計時には常に意識したいと思います。
0
来客者テーブルを作って、来客者種別に「求職中」とか「取引顧客」とかいれて、
来客予定テーブルの目的種別に「面接」とか「打ち合わせ」とかいれてやれば、nullとか考える必要ない気がするが、、、
つまりer設計しません？
投稿2016/10/25 05:25
総合スコア42
回答ありがとうございます。
「面接予定テーブル」を「来客予定テーブル」に一般化したように、「応募者テーブル」を「来客者テーブル」に一般化すれば良いのでは、ということですね。
当初の目的が採用部門で利用する応募者の管理システムだったため、その他の来客者情報もシステム内で管理する、という発想がありませんでした。
仰る通り、来客者テーブルとして運用した方がより広く、多様な情報を管理できるシステムになると思います。
しかし今回は応募者に関する情報管理と、来客予定に関しては応接室の空き状況が把握できればいい、ということなので質問文に記載した３テーブルで進めたいと思います。
（その他の来客者について詳細な情報管理しているわけではないようなので、作業量が増えるという懸念もあります…）
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/10/22 00:12