データベース設計におけるNULL - kawasima

NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。

[circled]

「なるほど、こうやってリレーションで分ければ良いんですね」って納得した若いエンジニアが、翌月盛大にN+1なコードを随所に書いて持って来てから次の教育が始まる。

[masatomo-m]

簡潔にまとめられていて良い。あとは現場レベルでは正規化に伴う新しい概念に名前を付けること自体が負担になってしまい、誤解がそれほどなければNULLでお茶を濁すケースはあると思う

[takeag]

カラムがnullでそんなに困ることないんだけどそんなに悪いもんなの？ 外部テーブルの存在確認の方がコスト高そうだけど。

[devrabi]

実装の話と実行コストの話もないと、この考え方はなかなか広まらないのが。

[kagehiens]

いい整理だと思う。まぁマスタ的に「参照しているイベントがないことが分かりきっている」値の属性にはNullをセットしておくのが最適解になりがちな訳ですが……。非存在の確認クエリはコスト上昇しまくるんだよなぁ

[fal-works]

本当にNULLが相応しいケースって実はそんなになくて、実装都合との綱引きの側面が強いですよね（そう多くの事例を知ってるわけではないが）。細部のポリシーは人によるかもですがこの整理は分かりやすい

[n314]

教科書的にはnullにindexは使えないけど、実際には使える実装もあるし部分indexもあるからnullが検索しやすい。テーブル分けたらnot existsとかseq scanになることが多くならないだろうか？

[strawberryhunter]

ナルフォビア諸氏の教条的思考回路に惑わされないためにNULLABLEにする基準は明確化しておきたい。私はNULLABLEはできるだけ避けつつ1列程度をテーブルに分割するくらいならNULLABLEでいいだろ派。

[turanukimaru]

属性とリレーションを正しく区別できる人はいない全ての属性はリレーションにできる。のでこの辺はあまり興味がない。私が気にしてるのはそのNullに意味が有るか？だけかな。未決定以外にNullの意味があるときは危ない

[qtamaki]

色々理由をつけてテーブルをバラしていくとRDBの上にRDBを構築することになって使いづらく重いDBが出来上がる。あと継承はOOPですら忌避される傾向にあるのでDBで使う野は地獄だ

[uesima]

データベース

[tor4kichi]

DB無知太郎だけどデフォNOT NULLで必要なやつだけNullable属性付けさす方が安全かなとおもた。出来るもんなら判別共用体みたいな複雑な型をテーブル項目として対応してもらえるといいけど、それは性能が犠牲になるよね…

[diveintounlimit]

DBのNULLの性質を知った上でどこまで正規化するかだろうという気はする。しようと思えば無限に正規化できて、無限にテーブルが生成できて、そして負荷と管理コストで死ぬ。

[nilab]

データベース設計におけるNULL - kawasima

[tmatsuu]

わいわい。NULLに関してはソフト・リサーチ・センター社の書籍でNULLを使わないスキーマ設計の話があって衝撃を受けた記憶がある。

[ko-ya-ma]

safari

[mather314]

「将来的な拡張性のためにdata1カラムを用意したが現時点で未使用のため全データでnull」というダメな事例は見たことある

[rryu]

スキーマ上NULLが存在していなくてもJOINすると現れるのでどうJOINするかも設計しておく必要があるが、NULLが現れる方法でしか利用できないのであれば最初からくっつけておけばいい訳である。

[honeningen]

ミドルネームを持たない人はNULLにした結果、名 || ミドルネーム || 姓でフルネーム表示してるところにミドルネームを持たない人の名前が出ないバグが発生するよな。

[so-apps]

アプリケーションの要求次第かな。ストレージをIDで埋め尽くす設計は嫌い。何度も退職するのでなければ、NULLにしておくのが地球にやさしい。

[surume000]

第5正規形というディストピア

[syusuimaru]

部分インデックスとか使うから絶対にnullをなくせってのは正直受け入れられんなぁ。

[yarumato]

“属性の値としてのNULLだが、主には未知(Unknown)と適用不能(Not Applicable)に区別される。”

[txjp]

状態ごとにテーブルを分けるのは想定外の値の持ち方をしたときのエラーハンドリングで地獄を見ることになる（なった）

[pascal256]

後で読む

[everybodyelse]

とりあえず気軽にメールアドレスだけ登録させておいて、後で必要なタイミングで他の情報も登録させる、みたいなのもあるよね。UX上の理由みたいな。この場合はテーブルを分けるべきではなさそう。

[kazukan]

Nullがやってくると信じてたら元がhostで空白スペース埋めて来た時の絶望感(テーブル定義が整備されてないことが発覚して、オープン化のプロジェクトの雲行きが怪しくなる序章)

[canadie]

Nullの弊害ねえ。価格をNullにすると消費税も合計も年売上も会社の総資産も全部NullになっちゃうNull伝播、言語側でUndefinedとかぬるぽとか0とかになっちゃう問題、とかかな？パフォーマンス面では改善されている認識

[zentarou]

APIでJSON返す時に結局NULLになっちゃったりフロントに面倒さを押し付けたりしないといいんだけど

[door-s-dev]

NULLがあるとほんと考えるケース増えるしSQLも複雑になるからね。リンク先の3値論理の話がすごく良い

[Magicant]

みんな、速度やデータサイズを犠牲にしてでもそこまでマジメに正規化したがるもんなの?

[razokulover]

NULL

[shodai]

面白い