1
SQL Serverでのvarcharのサイジングに関する現在のベストプラクティスは何ですか?
ストレージとパフォーマンスの両方の観点から、varchar列の大きさを決定する最良の方法を理解しようとしています。 パフォーマンス 私の研究から、それはそうですvarchar(max)は、本当に必要な場合にのみ使用してください。つまり、列が8000文字以上を収容する必要がある場合、1つの理由はインデックス作成の欠如です(ただし、一般にvarcharフィールドでのインデックス作成には少し疑いがあります。ただし、DBの原則はかなり新しいので、それが根拠がないかもしれません。 )および圧縮(より多くのストレージの問題)。実際、クエリは可能な最大サイズを考慮しなければならないため、一般的に人々はvarchar(n).... oversizingを行うときに必要なものだけを使用することを推奨しているようです。しかし、エンジンはデータの実際の平均サイズの推定値として、示されたサイズの半分を使用することも述べられています。これは、データから平均サイズを決定し、それを2倍にし、それをnとして使用する必要があることを意味します。ただし、変動性が非常に低いがゼロではないデータの場合、これは、最大サイズの最大2倍のサイズ変更を意味します。洞察をいただければ幸いです。 ストレージ 実際のストレージは実際のデータに制限されていることを念頭に置いて、行内ストレージと行外ストレージのしくみについて読んだ後、nの選択はストレージにほとんどまたはまったく影響がないように思えます(それがすべてを保持するのに十分な大きさであることを確認してください)。varchar(max)を使用しても、ストレージに影響はありません。代わりに、可能であれば、各データ行の実際のサイズを〜8000バイトに制限することが目標になる場合があります。それは物事を正確に読んでいますか? コンテキスト 一部の顧客データは少し変動するため、通常、必要な列よりも少し幅を広く(たとえば15〜20%大きく)します。他に特別な考慮事項があるかどうか疑問に思っていました。たとえば、一緒に仕事をしている人から、2 ^ n-1サイズを使用するように言われました(ただし、それを証明するものは見つかりませんでした。 最初のテーブル作成について話している。新しいテーブルの送信を開始し、サンプルデータ(または最初の本番データセットのみ)を送信することをお客様から言われます。これを見て、データを保持するためのテーブルを作成します。将来のインポートとサンプルの内容を処理できるように、テーブルを作成します。ただし、特定の行は長くなるようにバインドされているため、それらをパディングします。 問題はどれくらいか、そして技術的なガイドラインはありますか?