アカウント名:
パスワード:
Allow col IS NULL to use an index
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
他にもうれしい部分 (スコア:3, 参考になる)
まぁ、今回は8.1→8.2以上に変更点が多いとどこぞで聞いた記憶もあるので、移行には十分なテストが必要でしょうけど。
# 追跡していたのにリリースに気づいてなく、タレコミに先を越されたので悔しいからID
Re: (スコア:1, 興味深い)
元々SQLのNULLは、データ無しとか未入力とかいう意味じゃなく、
データが有るか無いかすら「不明」って意味だ。
(だから大抵の式(関数や演算子)にNULLを1つでも食わすと式全体の値がNULLになる。
不明を1つでも食わせりゃ全体が不明に汚染されるってことだ。)
一方「不明」なんてな状態を許す必要が有るカラムは
現実的にはそう多いわけでもない。
実際に欲しいのは「不明」ではなく「なし」や「未入力」のほうだということが多い。
(そういう意味では、NULLのときindexが効かないという制限をRDBが持つのはそれなりに合理的)
なのにSQLには「なし」「未入力」を表す合理的な道具が無
Re: (スコア:3, 興味深い)
元々も何も極初期のSQLにはnullなんてものはなかったはずだが。徹底的に正規化すれば「なし」に相当する値が必要になることはありません。存在しないデータは最初からDBに入れなければよいだけです。例えばユーザ表にIDとユーザ名と生年月日のカラムがあって、生年月日未入力がありえるなら、単にそれをユーザ名表とユーザ生年月日表に分ければよろしい。
そうしないで生年月日カラムにnullを入れるなら、それは単にパフォーマンスチューニングのために正規化をくずしているということなので、それなら効率化のためなら何でも遠慮なくできた方がいいでしょう。
Re:他にもうれしい部分 (スコア:0)
元ACじゃないですけど
つまりは、例えば ID:生年月日 で表作っといて、IDで検索して見つからなければ生年月日入力されてないという判断を下すってコトですかね。
生年月日入力が無いIDの一覧を得るって言う利用方法を考えなければおっしゃる通りなのでしょうね。
たぶん、分析とサービス特化とかの立場の違いなんですかね。
#個人的にはNULLがほしいAC
Re: (スコア:0)
table human=(id, name)
table birthday=(human_id, date)
select human.id
from human, birthday
where
human.id = birthday.human_id(+)
and
human_id is null
…おっと、is nullが使えない世界の話だっけ。
もっと込み入ったSQLを書いて
SQL呼び出し回数もケチらなければ
なんとか(なんとでも)なるけど、
それじゃ人間も計算機も手間ですね。
Re: (スコア:0)
Re: (スコア:0)
使い勝手としてはイマイチかな位。
#スパッと検索条件指定できたほうが気持ちいいと思うだけのAC