VARCHAR列のサイズを小さくすることに意味はありますか？

VARCHAR2Oracleの列のサイズがパフォーマンスに影響するかどうかに関係なく、あちこちでグーグルでレポートが混在しているようです。

VARCHARサイズの問題に少しひねりを加えたいと思います。

（複数行）フリーテキストフィールド（与えられていないあなたは（オラクル）データベースに格納することを名前のような短いもの）、内の任意の点（WRT。パフォーマンスやそれ以外）が存在しない限界いっぱいまでVARCHAR（容量VARCHAR2(4000)Oracleの上に）が、選択は、とにかく98％のケースで十分であるため、1024や512などの小さい値。

特にクライアントプログラムがデータセットを受信するために十分なメモリを割り当てる必要がある場合、メモリ使用量に影響します。

多くのアプリ（特にWebアプリ）は、マルチバイト文字セットであるUTF-8を使用していることに注意してください。そのため、バイトではなく文字を実際に考慮する必要があります。

1000文字以上を期待している場合、CLOBを積極的に検討します。プレーンテキストまたはマークアップ（wiki / html？）のいずれかの形式、非ユーロ言語での使用を格納するかどうかを考えています。たとえば、ここでの質問と回答はCLOBですが、コメントはVARCHARに収まります。

VARCHARを最大にすると、6か月後に誰かが再びそれを大きくしたいと思うでしょう。そして、CLOBを使用しないことで自分を蹴ります。

通常、パフォーマンスに関する考慮事項はありませんが、重要な副次的な問題があります。の制限は、varchar他の制限と同様に考える必要があります-ビジネスルールを実施するためにあります。

IMOの質問は「このフィールドに保存されているフリーテキストデータがnバイト/文字より長くなるのを防ぎたいですか」です。これがvarchar(512)とを選択する際の唯一の決定要因varchar(4000)です。

私はあなたがvarcharSQLタイプについて話していると仮定していることに注意してください-状況は異なるため、メモリ割り当ての理由からpl/sql長さを選択することが重要になる場合があります。

小さい値がケースの98％で機能するが、ケースの100％で機能するためにVarchar2（4000）が必要な場合、大きい値を使用する以外に選択肢はほとんどありません。値の2％に個別のテーブルを作成し、挿入/選択などを調整すると、複雑さが増し、フィールドを拡張しないことによるメモリやパフォーマンスの利点が失われます。