アカウント名:
パスワード:
よくあるバグですね.
データベース(SQLやCSV)で「ワクチン接種の有無」という項目をつくり値は,有,無,NULL,の3値となるような設計&実装をしますつまり,不明の場合はNULL,確定した場合は有or無, です.
これを2値と勘違いして,「有」と「それ以外(つまりNULL or 無)」と集計したりSQLで SELECT * FROM hogehoge WHERE "ワクチン接種の有無" == TRUE などとクエリを書いてしまうと,今回のようなバグが発生します.
ワクチン接種の有無,という一見2値のような項目名に対して,データは3値になるという「矛盾」が混乱を招くのでしょう.(今回の場合は,日付の入力がある or 無い(=NULL) or 不明(=NULL)の3状態を接種済みと未接種(=NULL)の2状態に誤分類したバグ)
NULLに関わるバグ・不具合はデータベース界隈では頻繁に生じています.プログラムやデータベースをいじったことがある人なら同種のバグに遭遇し,「NULLは糞」「NULLなんて許容したやつは誰だ?」と苛ついた経験がある人も多いはずです.
私は,仕様書などでNULLを見かけたら- NULLは諸悪の根源!- 集計する際,デバッグする際は必ずNULLの有無を確認!と肝に銘じてから実装や集計を始めるようにしていますが,それでも先日NULLで1箇所失敗していました.
よくあるミスなので,本件も寛大に受けて止めてあげてください.NULLが悪いんです.NULLが.
ハーシス最初の頃は、ワクチン打った日がわからなくても、打ったことがわかっていいれば接種済で入力できたんだよな、途中から、打った日付が分からないと、不明でしか、入力できなくなったような陽性判定出たらすぐにハーシス入力しないといけないのに、患者がその場で打った日を3回共正確に言えると思う?ほとんどいないよ。途中から、接種済の人たちはほとんどみんな、不明になってたよ。だって、不明にしないと先に進めないんだもん。届け出できないんだもん。その他、先には進めるけど変な項目を入力しろとのたまってくるシステム。デ
いやNULLに罪はない。罪があるのは設計者か、或いは実装者か、またはその両者だ。
同意です。Nullを受け付けないRDBMSがあったとすればポンコツでしょう。
The net of all this is that if nulls are present, then we’re certainly not talking about the relational model.
ゆうてもRDBMSの権威、C.J.Dateもこう言ってるしなぁ。
全てのColumnにNot Null制約をつけて運用できますか?
いや、テストしろよとしか…テストデータ入れて集計値が想定通りかチェックすれば即確認できる項目でしょ
>いや、テストしろよとしか…テストデータ入れて集計値が想定通りかチェックすれば即確認できる項目でしょ
記載してない、という状態を想定できてなかったのでそういうテストデータを作ってなかった、という問題だと思いますけど
# 想定していない問題のテストデータをどうやって作る気?
問題外やん。政府の公式の統計がそんなんて。
テストケースが事象を網羅出来てない、それはテスト出来てないのと同じですよ
有無の二値で済むと誤認するのが問題になるという話に対し、テストできてる・できてないの二値で済まそうとする議論を持ってきちゃうのが素敵です
NULLABLEな項目ならばNULLが入るだろ。想定出来ないわけないじゃん。
NULLABLEかどうかは設計書に書いてないとわかんないよ。NULLABLEって書いてあったとしても、NULLが何を示すかも設計書に書いてないとわかんないよ。
想定してないデータが来た時のテストケースってやらないの?想定していないデータが来た場合、エラーで止めるなり、それなりの処理を行ってシステムにダメージを与えないようにするもんだと思ってたんだが・・・#そういった想定外のテストデータを嬉々として作る私はある意味性格のゆがんでいるんだろうな
最初に if(0 == NULL) を真にした奴は誰なんだろうな…
苗字は野々村
K&Rの頃からじゃね?
今回は>「有」と「それ以外(つまりNULL or 無)」これだったんだと思うが。
「2値」という勘違いなら、SQLで単に==TRUE/FALSE(!=でも)ではNULLが取れないから件数が合わない。
いや、普通にNULL無いと困るだろ。諸悪の根源はNULLではなく、仕様書を良く読まずに勘違いしたまま実装しちゃう方々ね。
例えば計算結果を格納するintカラムにおいて、not nullにしたら計算をした結果の0と初期値の0とを見分けなければ行けないという点で、nullは有用に思える。が、その他のnullの悪行を考えると、冗長に見えようと、calculatedのboolカラムを別で持たせる方法を私は採用するよ。
そのような手法を用いてもアプリケーション実装側が意識しないといけないのは同じです。intカラムで0と初期値の0を区別せずに集計してしまう問題が起きます。
nullのほうが一般的だろうと思います。
今回のに関して言えば、「ワクチンは打った。」「だが、いつどこで打ったか記憶に御座いません。」なんて、いかにも反ワクチンが言いそうな、怪しげな発言だからじゃないか。
こういう場合に、とりあえず未接種扱いで処理するのは理解出来る。例えばワクチンパスポートの運用においては、書類に記述ミスや不正があれば不許可の方向で処理するんじゃないか。
日本語使えとしか言いようが無い日本語で「有」「無」「不明」とか「有」「無」「その他」とかに区分して、プログラミング上の概念であるNULLなど排除したら良いのにそう出来ない理由があるのだろうか?(まあコーディング上、いろんなチェックのためにNULLがあちこちで出てくる・使わざるを得なくて混同が生じるというのは分かるものの....)
日本語を用いず単純な(?)2値を用いるのはミスを減らすためだったりシステムを軽くするためだったり集計を容易にするためだったりするので、それでもミスするような開発者が悪いという結論にたどり着く。親コメはそこまで考えて風刺的に書いていると思われる。
「有無」の指定ならその2つ以外は何があろうと受け入れてはならないのに何故「不明」を許可するのか…w
それ単に三値論理も関係モデルもまともに理解してないだけじゃん
3値論理 ―― 神のいない論理 [sakura.ne.jp]
誕生日が未知のトーバルズは、誰とも誕生日が一致しない人物として扱われるのです。この点に違和感を覚える人もいるでしょう。確かに現在のところ彼は誕生日を公開していないかもしれない。でもいつの日か新聞に誕生日が載るかもしれない。だから彼は全員と誕生日が一致する人物として扱われるべきではないか、と。しかし残念ながら、現在の RDBMS において、その直観は保証されません。
3値論理より様相論理で「誕生日が一致する可能性がある」が自然かなあ
NULLを「罷免を不可」側にカウントしてしまっているのが「最高裁判所裁判官国民審査」。
#N/A なり NaN なり、欠損したデータを扱えた方が都合がいい場面があるからなあ
接種日不明を接種の有無と同じレベルで設計してる点が一番の根本原因だと思うけど、殿上人の厚生労働省様がアンケートの紙を御創り遊ばしたのが先にあって実装するn次受けにとっては不可侵の聖典化して変えられなかったのかなーとか妄想が膨らむそもそも接種の有無がnullなら接種日が確認できないではなく、接種自体を確認できなかったになるんじゃないかな?(重体で意思疎通が不能とか)この辺は殿上人のボタンの掛け違いから起こる本来は不必要な複雑さをどこで実装するのがマシかという話にしかならないけど
#あと顧客側の入力でboolean使うのは結構危ない(客の言うことはコロコロ変わる)
「Null」さんはアンリ・マユだったのか!?
プログラマを悩ます人名:「Null」さんhttps://it.srad.jp/story/13/08/02/0546248/ [it.srad.jp]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
NULLは諸悪の根源 (スコア:5, すばらしい洞察)
よくあるバグですね.
データベース(SQLやCSV)で「ワクチン接種の有無」という項目をつくり
値は,有,無,NULL,の3値となるような設計&実装をします
つまり,不明の場合はNULL,確定した場合は有or無, です.
これを2値と勘違いして,「有」と「それ以外(つまりNULL or 無)」と集計したり
SQLで SELECT * FROM hogehoge WHERE "ワクチン接種の有無" == TRUE などとクエリを書いてしまう
と,今回のようなバグが発生します.
ワクチン接種の有無,という一見2値のような項目名に対して,データは3値になるという「矛盾」が
混乱を招くのでしょう.(今回の場合は,日付の入力がある or 無い(=NULL) or 不明(=NULL)の3状態を
接種済みと未接種(=NULL)の2状態に誤分類したバグ)
NULLに関わるバグ・不具合はデータベース界隈では頻繁に生じています.
プログラムやデータベースをいじったことがある人なら同種のバグに遭遇し,
「NULLは糞」「NULLなんて許容したやつは誰だ?」と苛ついた経験がある人も多いはずです.
私は,仕様書などでNULLを見かけたら
- NULLは諸悪の根源!
- 集計する際,デバッグする際は必ずNULLの有無を確認!
と肝に銘じてから実装や集計を始めるようにしていますが,それでも先日NULLで1箇所失敗していました.
よくあるミスなので,本件も寛大に受けて止めてあげてください.NULLが悪いんです.NULLが.
いくら払ってシステム組んでる (スコア:2)
君の思う3倍以上だぞ
Re: (スコア:0)
ハーシス最初の頃は、ワクチン打った日がわからなくても、打ったことがわかっていいれば接種済で入力できたんだよな、
途中から、打った日付が分からないと、不明でしか、入力できなくなったような
陽性判定出たらすぐにハーシス入力しないといけないのに、患者がその場で打った日を3回共正確に言えると思う?ほとんどいないよ。
途中から、接種済の人たちはほとんどみんな、不明になってたよ。だって、不明にしないと先に進めないんだもん。届け出できないんだもん。その他、先には進めるけど変な項目を入力しろとのたまってくるシステム。デ
Re:NULLは諸悪の根源 (スコア:1)
いやNULLに罪はない。
罪があるのは設計者か、或いは実装者か、またはその両者だ。
Re: (スコア:0)
同意です。
Nullを受け付けないRDBMSがあったとすればポンコツでしょう。
Re: (スコア:0)
ゆうてもRDBMSの権威、C.J.Dateもこう言ってるしなぁ。
Re: (スコア:0)
全てのColumnにNot Null制約をつけて運用できますか?
Re: (スコア:0)
いや、テストしろよとしか…テストデータ入れて集計値が想定通りかチェックすれば即確認できる項目でしょ
Re:NULLは諸悪の根源 (スコア:1)
>いや、テストしろよとしか…テストデータ入れて集計値が想定通りかチェックすれば即確認できる項目でしょ
記載してない、という状態を想定できてなかったのでそういうテストデータを作ってなかった、という問題だと思いますけど
# 想定していない問題のテストデータをどうやって作る気?
Re: (スコア:0)
問題外やん。
政府の公式の統計がそんなんて。
Re: (スコア:0)
テストケースが事象を網羅出来てない、それはテスト出来てないのと同じですよ
Re:NULLは諸悪の根源 (スコア:2, 興味深い)
有無の二値で済むと誤認するのが問題になるという話に対し、
テストできてる・できてないの二値で済まそうとする議論を持ってきちゃうのが素敵です
Re: (スコア:0)
NULLABLEな項目ならばNULLが入るだろ。
想定出来ないわけないじゃん。
Re: (スコア:0)
NULLABLEかどうかは設計書に書いてないとわかんないよ。
NULLABLEって書いてあったとしても、NULLが何を示すかも設計書に書いてないとわかんないよ。
Re: (スコア:0)
想定してないデータが来た時のテストケースってやらないの?
想定していないデータが来た場合、エラーで止めるなり、それなりの処理を行ってシステムにダメージを与えないようにするもんだと思ってたんだが・・・
#そういった想定外のテストデータを嬉々として作る私はある意味性格のゆがんでいるんだろうな
Re: (スコア:0)
だっただけだろ
それなりの処理じゃダメってこったよ
Re: (スコア:0)
最初に if(0 == NULL) を真にした奴は誰なんだろうな…
Re: (スコア:0)
苗字は野々村
Re: (スコア:0)
K&Rの頃からじゃね?
Re: (スコア:0)
今回は
>「有」と「それ以外(つまりNULL or 無)」
これだったんだと思うが。
「2値」という勘違いなら、SQLで単に==TRUE/FALSE(!=でも)ではNULLが取れないから件数が合わない。
Re: (スコア:0)
いや、普通にNULL無いと困るだろ。
諸悪の根源はNULLではなく、仕様書を良く読まずに勘違いしたまま実装しちゃう方々ね。
Re: (スコア:0)
例えば計算結果を格納するintカラムにおいて、
not nullにしたら計算をした結果の0と初期値の0とを見分けなければ行けないという点で、nullは有用に思える。
が、その他のnullの悪行を考えると、冗長に見えようと、
calculatedのboolカラムを別で持たせる方法を私は採用するよ。
Re: (スコア:0)
そのような手法を用いてもアプリケーション実装側が意識しないといけないのは同じです。
intカラムで0と初期値の0を区別せずに集計してしまう問題が起きます。
nullのほうが一般的だろうと思います。
Re: (スコア:0)
今回のに関して言えば、
「ワクチンは打った。」
「だが、いつどこで打ったか記憶に御座いません。」
なんて、いかにも反ワクチンが言いそうな、
怪しげな発言だからじゃないか。
こういう場合に、とりあえず未接種扱いで処理するのは理解出来る。
例えばワクチンパスポートの運用においては、書類に記述ミスや
不正があれば不許可の方向で処理するんじゃないか。
日本語使え (スコア:0)
日本語使えとしか言いようが無い
日本語で「有」「無」「不明」とか「有」「無」「その他」とかに区分して、プログラミング上の概念であるNULLなど排除したら良いのに
そう出来ない理由があるのだろうか?
(まあコーディング上、いろんなチェックのためにNULLがあちこちで出てくる・使わざるを得なくて混同が生じるというのは分かるものの....)
Re: 日本語使え (スコア:2)
日本語を用いず単純な(?)2値を用いるのはミスを減らすためだったりシステムを軽くするためだったり集計を容易にするためだったりするので、それでもミスするような開発者が悪いという結論にたどり着く。親コメはそこまで考えて風刺的に書いていると思われる。
Re: (スコア:0)
「有無」の指定ならその2つ以外は何があろうと受け入れてはならないのに何故「不明」を許可するのか…w
Re: (スコア:0)
それ単に三値論理も関係モデルもまともに理解してないだけじゃん
Re: (スコア:0)
3値論理 ―― 神のいない論理 [sakura.ne.jp]
Re: (スコア:0)
3値論理より様相論理で「誕生日が一致する可能性がある」が自然かなあ
Re: (スコア:0)
「誕生日が不明(unknown)の人と誕生日が一致するかどうかは不明(unknown)である」ならば、「誕生日が不明なトーバルズと誕生日が不明なトーバルズの誕生日が一致するかどうかも不明」になります。そんなはずはないです。たとえ誕生日が不明でもトーバルズの誕生日はトーバルズの誕生日と一致しているはずです。
というかこれがNULLを含む3値論理のよく知られた典型的な欠点です。
Re: (スコア:0)
NULLを「罷免を不可」側にカウントしてしまっているのが「最高裁判所裁判官国民審査」。
Re: (スコア:0)
#N/A なり NaN なり、欠損したデータを扱えた方が都合がいい場面があるからなあ
Re: (スコア:0)
接種日不明を接種の有無と同じレベルで設計してる点が一番の根本原因だと思うけど、殿上人の厚生労働省様がアンケートの紙を御創り遊ばしたのが先にあって実装するn次受けにとっては不可侵の聖典化して変えられなかったのかなーとか妄想が膨らむ
そもそも接種の有無がnullなら接種日が確認できないではなく、接種自体を確認できなかったになるんじゃないかな?(重体で意思疎通が不能とか)
この辺は殿上人のボタンの掛け違いから起こる本来は不必要な複雑さをどこで実装するのがマシかという話にしかならないけど
#あと顧客側の入力でboolean使うのは結構危ない(客の言うことはコロコロ変わる)
Re: (スコア:0)
「Null」さんはアンリ・マユだったのか!?
プログラマを悩ます人名:「Null」さん
https://it.srad.jp/story/13/08/02/0546248/ [it.srad.jp]