varchar（8000）を設定するとどのような結果になりますか？

varcharはフィールドのサイズに比例してディスク領域を使用するため、たとえばvarchar(8000)SQL Serverで、varcharを常に最大値として定義する必要がない理由はありますか？

テーブルを作成するときに、誰かがやっているのを見たらvarchar(100)、あなたは間違っていると言ってはいけませvarchar(8000)んか？

• 長さはデータの制約です（CHECK、FK、NULLなど）
• 行が8060バイトを超えるときのパフォーマンス
• 一意の制約またはインデックスを持つことはできません（キー列の幅は900未満でなければなりません）
• デフォルトはSET ANSI PADDING ON =多くの後続スペースが格納される可能性がある
• SQL Serverは、ソート操作の平均長を4000と想定し、これに基づいてメモリを割り当てます（これをバックアップするリンクを見つける必要がありますが、実行中に私を錆びさせます:-)

要約：しないでください。

SQL Serverを参照していると仮定すると、1つ考えることができます。

テーブル内の行のサイズ（8K）には制限があり、SQLでは理論的にその制限を超える可能性があるvarcharフィールドを定義できます。そのため、ユーザーが関連するフィールドに大量のデータを入力すると、エラーが発生する可能性があります。

SQL 2K8以降では、この制限を超えることができますが、パフォーマンスへの影響があります。

また、データがどのように見えるかを予測するためにサイズを制限する妥当性チェック全体があります。無制限の長さフィールドが必要な場合は、テキストまたはntextを選択してください。

確かに、フィールドに保存されている情報に依存しますか？

いくつかの事柄にはいくつかの理由で最大長がありますが、最大長が必要な場合はフィールドの長さになります。

理論的に最大長がない場合、なぜvarcharが使用されるのか疑問に思うでしょう。

Oracleデータベースのコンテキストでは、データベースの列に常に最小のフィールドサイズを使用すると、1つの落とし穴があることを学びました。

インポートエクスポートを介して、シングルバイト照合を使用するデータベースからマルチバイト照合を使用するデータベース（Oracle XEなど）にデータを移動すると、バイト長が長くなり、インポートによって作成されたテーブルへのデータのインポートが失敗します。Oracleには、varchar2の長さをcharまたはbyteとして定義するオプションがあります。

ここでの私のポイントは、常にできるだけ小さいフィールドを定義することが常に賢明というわけではないということです。後でフィールド変更を増やすために、多くの変更テーブルを見てきました（要件の変更が原因です）。

ここでは、20％〜100％の未使用フィールドを使用することを検討できます。