2022/05/21 01:45
masatomo-m
簡潔にまとめられていて良い。あとは現場レベルでは正規化に伴う新しい概念に名前を付けること自体が負担になってしまい、誤解がそれほどなければNULLでお茶を濁すケースはあると思う
2022/05/21 03:27
fal-works
本当にNULLが相応しいケースって実はそんなになくて、実装都合との綱引きの側面が強いですよね(そう多くの事例を知ってるわけではないが)。細部のポリシーは人によるかもですがこの整理は分かりやすい
2022/05/21 07:30
kagehiens
いい整理だと思う。まぁマスタ的に「参照しているイベントがないことが分かりきっている」値の属性にはNullをセットしておくのが最適解になりがちな訳ですが……。非存在の確認クエリはコスト上昇しまくるんだよなぁ
2022/05/21 07:40
iekusup
ほー。
2022/05/21 07:47
ch1248
勉強になる。
2022/05/21 07:52
versatile
0, "", undef などが乱立する perl だと db の NULL をアプリケーションでうまくハンドリングするには ORM の実装を見る必要があった、ような気がする。もちろん乱立してるってのは不勉強による気のせいなんだけど、むずいよね
2022/05/21 08:07
devrabi
実装の話と実行コストの話もないと、この考え方はなかなか広まらないのが。
2022/05/21 08:44
circled
「なるほど、こうやってリレーションで分ければ良いんですね」って納得した若いエンジニアが、翌月盛大にN+1なコードを随所に書いて持って来てから次の教育が始まる。
2022/05/21 08:53
shodai
面白い
2022/05/21 09:00
strawberryhunter
ナルフォビア諸氏の教条的思考回路に惑わされないためにNULLABLEにする基準は明確化しておきたい。私はNULLABLEはできるだけ避けつつ1列程度をテーブルに分割するくらいならNULLABLEでいいだろ派。
2022/05/21 09:24
razokulover
NULL
2022/05/21 10:03
takeag
カラムがnullでそんなに困ることないんだけどそんなに悪いもんなの? 外部テーブルの存在確認の方がコスト高そうだけど。
2022/05/21 10:12
turanukimaru
属性とリレーションを正しく区別できる人はいない全ての属性はリレーションにできる。のでこの辺はあまり興味がない。私が気にしてるのはそのNullに意味が有るか?だけかな。未決定以外にNullの意味があるときは危ない
2022/05/21 10:18
Magicant
みんな、速度やデータサイズを犠牲にしてでもそこまでマジメに正規化したがるもんなの?
2022/05/21 10:23
n314
教科書的にはnullにindexは使えないけど、実際には使える実装もあるし部分indexもあるからnullが検索しやすい。テーブル分けたらnot existsとかseq scanになることが多くならないだろうか?
2022/05/21 10:51
door-s-dev
NULLがあるとほんと考えるケース増えるしSQLも複雑になるからね。リンク先の3値論理の話がすごく良い
2022/05/21 11:40
zentarou
APIでJSON返す時に結局NULLになっちゃったりフロントに面倒さを押し付けたりしないといいんだけど
2022/05/21 11:56
canadie
Nullの弊害ねえ。価格をNullにすると消費税も合計も年売上も会社の総資産も全部NullになっちゃうNull伝播、言語側でUndefinedとかぬるぽとか0とかになっちゃう問題、とかかな?パフォーマンス面では改善されている認識
2022/05/21 12:02
qtamaki
色々理由をつけてテーブルをバラしていくとRDBの上にRDBを構築することになって使いづらく重いDBが出来上がる。あと継承はOOPですら忌避される傾向にあるのでDBで使う野は地獄だ
2022/05/21 13:18
kazukan
Nullがやってくると信じてたら元がhostで空白スペース埋めて来た時の絶望感(テーブル定義が整備されてないことが発覚して、オープン化のプロジェクトの雲行きが怪しくなる序章)
2022/05/21 13:50
everybodyelse
とりあえず気軽にメールアドレスだけ登録させておいて、後で必要なタイミングで他の情報も登録させる、みたいなのもあるよね。UX上の理由みたいな。この場合はテーブルを分けるべきではなさそう。
2022/05/21 15:15
pascal256
後で読む
2022/05/21 15:53
txjp
状態ごとにテーブルを分けるのは想定外の値の持ち方をしたときのエラーハンドリングで地獄を見ることになる(なった)
2022/05/21 16:18
yarumato
“属性の値としてのNULLだが、主には未知(Unknown)と適用不能(Not Applicable)に区別される。”
2022/05/21 17:16
syusuimaru
部分インデックスとか使うから絶対にnullをなくせってのは正直受け入れられんなぁ。
2022/05/21 18:16
surume000
第5正規形というディストピア
2022/05/21 18:55
so-apps
アプリケーションの要求次第かな。ストレージをIDで埋め尽くす設計は嫌い。何度も退職するのでなければ、NULLにしておくのが地球にやさしい。
2022/05/21 19:20
honeningen
ミドルネームを持たない人はNULLにした結果、名 || ミドルネーム || 姓でフルネーム表示してるところにミドルネームを持たない人の名前が出ないバグが発生するよな。
2022/05/21 20:05
rryu
スキーマ上NULLが存在していなくてもJOINすると現れるのでどうJOINするかも設計しておく必要があるが、NULLが現れる方法でしか利用できないのであれば最初からくっつけておけばいい訳である。
2022/05/21 20:59
mather314
「将来的な拡張性のためにdata1カラムを用意したが現時点で未使用のため全データでnull」というダメな事例は見たことある
2022/05/21 21:14
ko-ya-ma
safari
2022/05/21 23:02
tmatsuu
わいわい。NULLに関してはソフト・リサーチ・センター社の書籍でNULLを使わないスキーマ設計の話があって衝撃を受けた記憶がある。
2022/05/22 10:37
nilab
データベース設計におけるNULL - kawasima
2022/05/22 13:11
diveintounlimit
DBのNULLの性質を知った上でどこまで正規化するかだろうという気はする。しようと思えば無限に正規化できて、無限にテーブルが生成できて、そして負荷と管理コストで死ぬ。
2022/05/22 15:26
tor4kichi
DB無知太郎だけどデフォNOT NULLで必要なやつだけNullable属性付けさす方が安全かなとおもた。出来るもんなら判別共用体みたいな複雑な型をテーブル項目として対応してもらえるといいけど、それは性能が犠牲になるよね…