主キー以外の項目にNotNull制約をつける理由について

> もうちょっと正規化して、別テーブルにしてもらえませんか？とお願いもしましたが、

> もう決まっているから駄目と言われました。
> それで一体どうすればいいのかわからなくなって、
> 全項目NotNullを外せばいいんじゃないか？と思って質問してしまいました。
>
> こういう場合、どういう対処が望ましいのでしょうか？

正規化できるのであれば正規化するに越したことはないですが、できないのであれば仕方がないでしょう。

NOT NULL 制約の有無はソート列として指定された列以外ではあまり影響を与えることはありません。ましてや、WHERE 句の条件にもならないような列ではなおさらのことです。

ただ、NOT NULL 制約を好き勝手に外す権利があるのであれば、好き勝手に正規化する権利が jack_s さんにあるような気がしなくもないですが・・・。

たとえばVB6.0やAccessのVBAのように、

NULLがあるといちいちIsNull関数を使用して処理分岐を行う必要がある
プログラミング言語を使用する可能性があれば、そういう設計にする
のもアリだと思います。
今はもう少数派かもしれませんが、
NULLという概念が薄かった汎用機のネットワーク型DBの名残で、
そういう設計をされる方も以前は多かったか。
#要するに設計がRDBでないという:-)

自分側で初期値も入れられない、さらに正規化も不可ということでしたら、

選択としては、

・NOT NULL制約をはずす
・自分の処理の部分を行わせる前に、サブシステム側でレコードが初期化されていることを保証してもらう

このくらいじゃないでしょうか。
ダメというなら解決策を説得するしかないでしょうね。

プログラムのバグ等により、データに間違って NULL が入ってしまわないようにするためです。

そして、最大の目的はデータとプログラムを切り離すためです。(DOA の概念。データベース内のデータは単独で意味を持つ。そもそも、データベースとは単にデータを入れる箱ではない)

一意制約やチェック制約、参照制約についても同様です。

特に、Oracle の場合は制約の有無によって実行計画が変わる場合があるので、そういう意味でも意味があると思います。例えば、ORDER BY 句で指定された列に索引が張られている場合、NOT NULL 制約がなければソート処理が行われますが、NOT NULL 制約があれば索引が使用できるためソート処理は発生しない可能性があります。(NULL のデータが索引にはないため。NOT NULL 制約がないと Oracle は ORDER BY でのソートに索引が使えることを理解できない)

プログラム側でチェック処理が常に完全に行われればよいですが、

その保証はありません。DB側でNOT NULLであれば、NULLであった
場合例外が発生しますので、絶対的なチェックの保証ができます。
チェックはプログラム側のみでよいというのであれば、それは
個人の判断になると思います。
プログラムとDBのほうでチェックを２重にすれば完璧です。