口実として、私は NULL 値と空の文字列の意味上の違いに精通しています。
多くのホスト名とその IP アドレスを (文字列として) 格納する MySQL テーブルがあり、ホスト名を解決できない場合に、より自然な (または効率的なストレージの観点から) どう思われるか疑問に思います。
NULL 値または空の文字列 (この場合、おそらく CHAR ではなく VARCHAR である必要があります)
私は NULL 値に傾向がありますが、これを確認または不確認にしたいと思います。
口実として、私は NULL 値と空の文字列の意味上の違いに精通しています。
多くのホスト名とその IP アドレスを (文字列として) 格納する MySQL テーブルがあり、ホスト名を解決できない場合に、より自然な (または効率的なストレージの観点から) どう思われるか疑問に思います。
NULL 値または空の文字列 (この場合、おそらく CHAR ではなく VARCHAR である必要があります)
私は NULL 値に傾向がありますが、これを確認または不確認にしたいと思います。
MyISAM MYSQLでは、 NULL を使用せずに行ごとに 1 ビットを保存します。ここに記載されているように:
列を NULL と宣言すると、許可される列の最大数を減らすことができます。MyISAM テーブルの場合、NULL 列には、値が NULL かどうかを記録するために、行に追加のスペースが必要です。各 NULL 列は 1 ビット余分に取り、最も近いバイトに切り上げます。
こちらもご覧ください:
さらに、NULL 自体はストレージ領域を必要としませんが、テーブル定義に NULL として定義された列が含まれている場合、NDBCLUSTER は 1 行あたり 4 バイト (最大 32 個の NULL 列) を予約します。(MySQL Cluster テーブルが 32 個を超える NULL 列から最大 64 個の NULL 列まで定義されている場合、行ごとに 8 バイトが予約されます。)
さらに、ここに記載されているデータベースの動作も高速になります(stackoverflowから取得-@DavidWinterbottomリンクが機能しなかったため、別のソースを追加しました)
インデックス、インデックス統計、および値の比較がより複雑になるため、MySQL が null 許容カウントを参照するクエリを最適化するのは困難です。null 許容カラムは、より多くのストレージ スペースを使用し、MySQL 内部で特別な処理を必要とします。null 許容列がインデックス化されると、エントリごとに余分なバイトが必要になり、MyISAM で固定サイズのインデックス (単一の整数列のインデックスなど) が可変サイズのインデックスに変換される可能性さえあります。
ほとんどの場合、NULL 以外の値は、他の集計関数と組み合わせるとより予測可能なCOUNT()
動作をしますが、必要に応じて NULL の動作を確認することもできます。
hereに記載されているように、たとえば、すべてのグループ (集計) 関数が NULL を無視するわけではなく、 NULL 値を含む列のCOUNT()
場合とは異なる結果が得られます。COUNT(*)
一方、他の指摘として、NULL はエントリの意味をより適切に反映します。これは不明な値であり、すべてのホストをカウントしたい場合は、おそらくCOUNT()
それとまったく同じように動作するでしょう。
最初に: NULLとEmpty-Stringの異なるセマンティクスをよく検討してください。
2 番目: NULL よりもEmpty-String の方がインデックス作成とフィルタリングがより適切かつ効率的に機能することを認識してください。そのため、本当に前者を意味する場合は後者を使用しないでください。
3 番目: NULLを使用するすべての式は、最初に NULL が宗教的に空の文字列(またはその他のコンテキスト的に有効な値)に結合されない限り、3 値論理の非直感的な影響を受けやすいことを認識してください。特に、排除中間の法則はもはや適用されないため、式A または ~Aは、 Aの評価がNULL項の評価を必要とするときはいつでもトートロジー的に真ではなくなります。これを忘れると、非常に微妙で見つけにくいバグにつながる可能性があります。
不等号演算子は、これを定期的に公開します。
When A has the value NULL:
The expression A = 0 returns false;
The expression A <> 0 returns false; and
The expression A OR NOT A returns false!
更新:
私のポイントの本質は、それらが同じ生き物ではなく、非常に異なる獣であるということだと思います. それぞれの場所があります。2 番目のアドレス フィールドは常に null 以外である必要があり (部分的または不完全なアドレスの入力を許可する場合を除く)、既定値は常に Empty-String の有効で既知の値である必要があります。NULL は、有効で既知の値が後で提供される場合に制限する必要があります。実際には、解決する必要がある何らかの検証エラーを通知します。
以下OPより。
行は更新されません。挿入時に、IP アドレスがあるか、または何もありません (解決できなかったため)。
応答:
次に、デフォルトとしてEmpty-Stringを使用し、フィールドを NON-NULL にすることをお勧めします。微妙な欠点があるため、必要な場合にのみNULLを使用してください。
オラクルは問題を解決し、両方を同じように解釈します。
Mysqlはそうではありません。私はそれを判断していませんが、個人的には好きではありません。したがって、コードを「標準化」するためにできる限りNULLを使用しています。
さらに、キーワードの重要性の観点から、NULL は、db セマンティクスで「不明」を意味するため、まさにあなたが望むものです。(間違っていたら訂正してください)
NULL
NULL の型は string とは異なりますが、を使用することをお勧めします。たとえば、この値を使用して行を除外したり、そのフィールドの値のタイプを検出したりする方が簡単です。