アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2■PHPerKaigi 2019の登壇資料です - https://phperkaigi.jp/2019/ - https://fortee.jp/phperkaigi-2019/proposal/328896eb-c084-41c9-847f-f0512a538811 ■前作 - 失敗から学ぶ、RDBの正規化の話 - https://soudai.hatenablog.com/entry/learn-from-failure-1
nullについて最後まで考える(1) --- T字形で消せるnull，消せないnull - 極北データモデリング
正美氏とかDateの本を読むと、Codd論文を理解するとnullの存在が許せなくなるのだなあ、と思う。 私はこのnull徹底排除の感覚が理解できていない。Codd論文読んだことないし。 比較演算や集計演算の対象に null が混入していると、直感に反する結果が出てくることがあるのはわかる。 同僚がnot null制約を付けていないのを見つけると「付けないとだめっすよ」と言ったりもする。 でも、これはわかった振りをしているだけなのだ。 nullがよくないのは当たり前として、あらゆるアプリケーションでnullを発生させないことができるのだろうか？ どうしても発生するケースがあるのだとすれば、どのnullはあってもよくて、どのnullはあってはならないのか？ where句に出現するnullと、サブクエリが返すnullと、アプリケーションに返されるnullと、罪の重さは全部同じなのか（違うんじゃな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース技術の羅針盤
