空の列はテーブルのスペースを占有しますか？
私は非常に基本的な情報から保持するテーブルを持っています。タイトルと日付フィールドがいくつかあります。 commentsというフィールドが1つあります。これはvarchar（4000）です。ほとんどの場合、空白のままにしますが、大量のデータがここに入力されることもあります。これは本当に悪いデザインですか？それともこれはわずかに非効率的ですか？
この列に個別のテーブルを作成する方が良いと思います。
注：これはSQL Server 2008です
より予測可能なパフォーマンスを得るには（およびページごとの行の変動が大きくなるのを避けるため）、このデータを関連するテーブルに保存することをお勧めします。一部のクエリ。この値がNULLである行は、スペースのオーバーヘッドに寄与しますが、これは最小限です。より重要なのは、1つのページが2行に収まり、次のページが500行に収まる方法です。これは実際に統計に影響を与える可能性があるため、これを分割して個別に格納し、すべての操作に影響を与えない方がよいでしょう。コアテーブル。
使用しないときは最小限のスペースで済みます
- nULLビットマップの1ビット
- 長さ2バイト（NULLの場合はゼロになります）
オーバーヘッドは最小限であり、最適化は時期尚早です。
問題があることがわかるまで、1つのテーブルに保管してください。 KISSを中断するには、外部結合を導入し、データのクエリでオーバーヘッドを追加します。
特にフィールドに常にデータを入力するとは限らない場合は、ページ密度を向上させ、断片化を減らすために、別のテーブルの方が良いと思います。
- データページは約8000バイトを保持します
- たとえば100バイトの行と4000バイトを超える行があります
- それらの長い行はそれ自体がページ上にあり、ページの残りの部分は、DBが使用する「無駄な」スペースですが、データを保持することはおそらくありません。
- ほとんど完全なページのレコードのその長いフィールドにデータを追加すると、ページがオーバーランし、残りのレコードを含むページへのポインタが生じる可能性があります。
これらすべての空のページとポインタは、パフォーマンスの低下につながります。可能であれば、そのフィールドを正規化してください。
この質問は非常に似ています： 余分な空の列はSQLテーブルのサイズに大きく影響しますか？
答えは「はい」のようですが、スペースを消費しますが、null値が多い列には圧縮アルゴリズムがあります。
デザインに関しては、これにリンクされた外部テーブルがあれば、よりクリーンなデザインになると思います。 null値が頻繁に含まれる列があると、データベースのユーザーは、注意していないと誤ってnull値を使用する可能性があるため、困難になります。したがって、データベースを使用するコードにはエラーチェックを含める必要があり、そこから醜くなります。
大丈夫です-既にvarchar列なので、データが含まれている場合にのみスペースを使用します。 intのようなnull可能な固定サイズの列がたくさんある場合、スペースの使用に問題があるかもしれません。
別のテーブルに置く限り、私は気にしないでしょう。 varchar（max）と行内/行外オプションの使用も確認できます。 繰り返しますが、おそらく時期尚早です。