Nullという姓は、多くのデータベースでどのように問題を引き起こしますか？

BBC に関する記事を読みました。彼らが言った例の1つは、姓が「Null」の人が一部のウェブサイトに詳細を入力するのに問題があるということでした。

彼らが直面しているエラーについての説明はありません。

しかし、私が知る限り、文字列 'Null'と実際のNull値は完全に異なります（データベースの観点から）。

これがデータベースで問題を引き起こすのはなぜですか？

データベースの問題は発生しません。データベースを理解していない開発者が作成したアプリケーションで問題が発生します。問題の根本にあるのは、多くのデータベース関連ソフトウェアがNULLレコードを文字列として表示することNULLです。その後、アプリケーションが文字列形式のNULLレコードに依存する場合（大文字と小文字を区別しない比較操作も使用する可能性が高い）、そのようなアプリケーションはすべての"null"文字列をNULL と見なします。その結果、名前Nullはそのアプリケーションでは存在しないと見なされます。

解決策はNOT NULL、データベース内のようにnull以外の列を宣言し、データベースレコードに文字列操作を適用しないことです。ほとんどの言語には、文字列レベルのインターフェイスを不要にする優れたデータベースAPIがあります。また、SQLインジェクションなどのその他のミスが発生する可能性が低いため、常に優先される必要があります。

特定の質問に答えるために、Webフォームとデータベースの間の一連のイベントに沿って多くのステップがあります。姓Nullが誤ってNULL値として解釈された場合、システムは完全に有効な名前を無効として拒否する場合があります。これは、amonが説明したように、データベース層で発生する可能性があります。ちなみに、これが特定の問題である場合、データベースはおそらくボビーテーブル攻撃とも呼ばれるSQLインジェクションに対してもオープンです。問題を引き起こす可能性のあるチェーン内の別のステップは、シリアル化プロセスです。

全体として、記事はより大きな問題についてでした。世界は大きな乱雑な場所であり、私たちの仮定に必ずしも従うとは限りません。これは、アプリケーションを国際化するときに特に顕著です。最終的には、アプリケーションがデータを適切に処理およびエンコードするようにする必要があります。ますます複雑化するエッジケースのサポートに専念するリソースの数を決定するのはビジネス次第です。私は包括的であることを完全にサポートしていますが、「プリンス」として正式に知られているアーティストは、データベースで彼の名前を表すためにユニコード文字を使用する必要があるとビジネスが判断するかどうかを理解します。

それは、データベースに入力される前に、DOM要素、次に渡され、検証され、操作されたjavascript変数、次にJSON値、次に使用しているバックエンドJSONライブラリ内の変数、そして渡された変数です。バックエンドプログラミング言語で検証、操作し、次にある種のDAOの要素、次にSQL文字列の一部です。その後、値を元に戻すには、すべてを逆に行います。それはプログラマーがミスを犯す多くの場所であり、通常は静的型付けの恩恵を受けずにそれをたくさん行います。

おそらくプログラミングの問題です。ここでNULLがどのように渡されるかについてのこの答えを見ると、「Mr。Null」だった場合に、望ましくない動作を簡単に引き起こす可能性があります。

https://stackoverflow.com/questions/4620391/mysql-and-php-insert-null-rather-than-empty-string

いくつかのデータ要素がNULLとして渡された場合、データはデータベース内のデータベースNULLとして補間されることがわかります。

"NULL"！=データベースヌル

いくつかのユースケースと関連する動作...

データベースで姓がnull以外としてマークされていたとします。データが挿入されると、NULLとして解釈され、挿入に失敗します。

もう1つのケースは、姓がデータベース内でNULL可能であったとしましょう。Mr. NULLが挿入され、「NULL」とは異なるDBNull.Valueに変換されます。挿入後、氏の姓は「NULL」ではなく、実際にはデータベースのNULL値であるため、Null氏は見つかりません。

したがって、それらは問題の2つのケースになります。@Amonが指摘しているように、データベース自体にはヌルに関する問題はありませんが、ベンダーごとに違いがあるため、各RDMSインスタンスでヌルがどのように処理されるかを理解する必要があります。

私は、問題の原因を、プログラミングの粗雑さと、SQLの一部の実装の不十分な設計にあると考えています。「ヌル」の名前は、常に提示し、引用符で解釈する必要があります。データベース値であるnullは、常に引用符なしで提示する必要があります。しかし、アドホックコードを記述する場合、「何でもできます」というパラダイムに陥りやすく、引用符で囲まれていない文字列と思われるものを受け入れるのは簡単です。

これは、他のタイプのデータという事実によってさらに悪化します。たとえば、数値は解釈が明確であるため、どちらの形式でも受け入れられます。

基本的に問題は、「null」という用語が2つの異なるデータベース概念に適用されることであり、コンテキストを使用してそれらを区別することもあります。

1. 何かに既知の値がありません
2. 何かが価値がないことが知られている

これらの概念を区別するにはコンテキストで十分な場合もありますが、そうでない場合もあります。たとえば、レコードを使用して検索クエリを保持している場合、「姓のない[何でも]という名前の人が欲しい」と「名が[何でも]しかし、その姓は不明です。」多くのデータベースエンジンは、ある意味または他の意味に偏っていますが、すべて同じではありません。異なる方法で実行される別のエンジンで実行すると、データベースエンジンが一方向に機能することを期待しているコードが誤動作する可能性があります。

既存の回答のほとんどは、アプリケーションの非SQL部分に焦点を当てていますが、SQLにも問題がある可能性があります。

ユーザーの姓が使用できないレコードを除外するように指示された場合、SQLを十分に理解していない人がフィルターを作成する場合がありますWHERE u.lastname != 'NULL'。SQLの動作方法により、これは以下をチェックするように見えますu.lastname IS NOT NULL：すべてのNULLレコードがフィルターで除外されます。非NULL記録はすべて残ります。

もちろん、レコードの場合は除きますがu.lastname == 'NULL'、テスト中にそのようなレコードが利用できなかった可能性があります。

SQLは、そのフレームワークが非をチェックするために簡単にアクセスできる方法で公開されていないフレームワークのいくつかの並べ替え、によって生成された場合、これは可能性が高くなったNULLパラメータで-nessを、私は、文字列を渡す場合、誰かが、ちょっと」気付きNULL、それは、まさに私が望むことをします！」