現在のプロジェクトでは、列を数文字だけ拡張する必要があることが頻繁に発生します。からvarchar(20)へvarchar(30)と上のようにします。
現実には、どれほど重要なのでしょうか？これはどの程度最適化されていますか？通常の「入力」フィールドに100文字、200文字、さらには500文字を許可した場合の影響は何ですか？メールには320文字しか使用できないため、OK-そこには十分な制限があります。しかし、200に設定した場合、それより長い電子メールアドレスは期待できないため、何を得ることができますか。
通常、テーブルには100.000行を超えることはなく、最大20または30個のこのような列があります。
現在SQL Server 2008を使用していますが、さまざまなDBがこの問題をどのように処理するかを知ることは興味深いでしょう。
影響が非常に小さい場合-予想どおり、この長距離パラノイアは実際には必要ではないと、DBAに納得させるために（リンクでバックアップされている？）良い議論を得るのに役立ちます。
そうである場合、私は学ぶためにここにいます:-)
回答:
あなたの質問に対する具体的な答えは（少なくともOracleとおそらく他のデータベースの場合）、フィールドの長さは問題ではなく、データの長さだけです。ただし、これをフィールドを最大許容長に設定するかどうかに関する決定要因として使用しないでください。フィールドサイズを最大化する前に考慮する必要がある他の問題を次に示します。
書式設定 フィールドのサイズに基づいてデータを書式設定するクライアントツールでは、特別な書式設定を考慮する必要があります。たとえば、OracleのSQL * Plusは、デフォルトでは、データが1文字のみの場合でもVarchar2列の最大サイズを表示します。比較…
create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;不良データ フィールドの長さは、不良データをキャッチ/防止するための追加のメカニズムを提供します。インターフェイスは、3000文字を100文字のフィールドに挿入しようとするべきではありませんが、そのフィールドが4000文字と定義されている場合は、そうするだけです。エラーはデータ入力段階では検出されませんが、別のアプリケーションがデータとチョークを処理しようとすると、システムでさらに問題が発生する可能性があります。例として、後でOracleのフィールドにインデックスを付けることにした場合、キーの最大長を超えます（ブロックサイズと連結に依存します）。見る…
create index i1 on f1(a);メモリ クライアントアプリケーションが最大サイズを使用してメモリを割り当てる場合、アプリケーションは必要以上のメモリを割り当てます。これを回避するには、特別な考慮が必要です。
ドキュメント フィールドのサイズは、データに関するドキュメントの別のデータポイントを提供します。すべてのテーブルt1、t2、t3など、およびすべてのフィールドf1、f2、f3などを呼び出すことができますが、意味のある名前を指定することで、データをよりよく理解できます。たとえば、米国に顧客を持つ会社の住所テーブルに2文字のStateというフィールドがある場合、2文字の州の略語が入力されると予想されます。一方、フィールドが100文字の場合、完全な州名がフィールドに入ると予想される場合があります。
言われていることはすべて、変化に備えることは賢明に思えます。今日のすべての製品名が20文字に収まるからといって、常にそうだとは限りません。船外に出て1000にしないでください。もっともらしい拡張の余地を残してください。
ここからが良い出発点です。
http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx
私はあなたの元の質問を誤解したかもしれません。参考のために他のリンクをいくつか見つけられるかどうかを確認させてください。
データ型の選択に関する適切なリファレンスを次に示します。http：//sqlfool.com/2009/05/performance-considerations-of-data-types/
varchar（20）からvarchar（30）に変更することは小さなことのように思えるかもしれませんが、潜在的な問題を認識するためには、データベース構造がどのように機能するかをさらに理解する必要があります。たとえば、varchar（30）に移動すると、列の転換点（30バイトすべてが使用される場合）を超えて1ページ（8060バイト未満）に格納できるようになります。これにより、使用されるディスク領域が増加し、パフォーマンスが低下し、トランザクションログにオーバーヘッドが追加されます。
データベース構造のリンクは次のとおりです。http：//technet.microsoft.com/en-us/sqlserver/gg313756.aspx
ページ分割とtrxロギングの1つを次に示します。http ://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx
HTH
次のSO質問で見つけた別の興味深い点を共有すると思いました。
/programming/148398/are-there-any-disadvantages-to-always-using-nvarcharmax
元の回答：Nick Kavadias
最大またはテキストフィールドを使用しない理由は、[オンラインインデックスの再構築] [1]を実行できない、つまり、SQL Server Enterprise EditionでもREBUILD WITH ONLINE = ONを実行できないためです。
[1]：http : //msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx 「オンラインインデックスの再構築」
n / varchar（max）列を任意に追加する場合、これは大きな欠点であると考えます。MSサイトによると、オンラインインデックスの再構築に対するこの制限はSQL Server 2008、2008 R2、およびDenaliに残っています。そのため、SQL Server 2005に固有のものではありません。
ありがとう、ジェフ
場合によっては、varcharフィールドに割り当てるスペースの量が、インメモリソートに割り当てられるメモリの量に影響することがあります。
SQLWorkshops.comでのプレゼンテーションは刺激的だと思いました。このプレゼンテーションでは、char / varcharフィールドに十分なメモリが割り当てられていないために、by byの並べ替えがtempdbにあふれている場合について説明しています。
http://webcasts2.sqlworkshops.com/webcasts.asp
このWebキャストは、次のWebサイトでも記事として紹介されました。
http://www.mssqltips.com/tip.asp?tip=1955
このプレゼンテーションでは、ソート対象の列はchar / varchar列ではありませんが、メモリ内のvarchar列に割り当てられたスペースの量によって、クエリのパフォーマンスが異なる場合があることに注意してください。
ディスク容量と文字の長さにのみ関係します。もちろん、charデータ型とこれらのデータ型のインデックスの検索は整数よりも遅くなりますが、これは別の議論です。
Varcharデータ型は「可変」データ型なので、varchar（500）の制限を設定した場合、これはそのフィールドの最大文字長になります。最小の長さは0〜500です。一方、10、30、または500文字のフィールドでは、請求されるディスク容量が異なります。
データ型varchar（800）のテストを行い、null値の場合は17バイトを使用し、挿入された各文字に対してもう1バイト追加しました。たとえば、400文字の文字列では、ディスクで417バイトが使用されていました。