[解決済み】SQLのvarcharカラムの長さに関するベストプラクティス【クローズド

質問

新しいSQLテーブルをセットアップするたびに、または新しい varchar カラムの最適な値は何でしょうか？ length .

というカラムがあるとします。 name 型の varchar . そこで、長さを選択する必要があります。名前 > 20文字というのは考えられませんが、わからないこともないでしょう。しかし、20を使う代わりに、私はいつも次の2^nの数字に切り上げます。この場合、私は32を長さとして選択します。なぜなら、コンピュータサイエンティストの観点からすると、2^nという数字はより多く見えるからです。 even は他の数よりも、その下にあるアーキテクチャがそれらの数を他の数よりもわずかにうまく処理できると仮定しているに過ぎないのです。

一方、例えばMSSQLサーバーでは、varcharカラムの作成を選択すると、デフォルトの長さの値が50に設定されます。そこで、私は考えてみました。なぜ50なのでしょうか。単なる乱数なのか、それとも平均的なカラム長に基づいているのか、それとも何なのでしょうか。

また、SQLサーバーの実装（MySQL、MSSQL、Postgresなど）が異なると、最適なカラム長の値が異なるということも考えられます（おそらくそうでしょう）。

解決方法は？

私が知っている限り、どのDBMSもこのような最適化を行っていません。 VARCHAR で 2^n 長さの方が max 2の累乗でない長さ

初期のSQL Serverバージョンでは、実際に VARCHAR は、長さ255のものとそれ以上の長さのものでは異なります。現在もそうなのかどうかはわかりません。

ほとんどすべてのDBMSにおいて、実際に必要となるストレージは、入れる文字数によってのみ決まるのであって max 長さを定義します。したがって、ストレージの観点からは（そしておそらくパフォーマンスの観点からも）、あるカラムを VARCHAR(100) または VARCHAR(500) .

が表示されるはずです。 max のために用意された長さです。 VARCHAR カラムを、技術的・物理的なものというよりも、一種の制約（またはビジネスルール）として使用することができます。

PostgreSQL の場合、最適な設定は text 長さ制限のない CHECK CONSTRAINT のように、ビジネスで必要な文字数に制限することができます。

その要件が変更された場合、チェック制約を変更する方が、テーブルを変更するよりもはるかに速いです（テーブルを書き直す必要がないため）。

Oracleなどでも同じことが言えます。Oracleの場合は VARCHAR(4000) ではなく text とはいえ

との間に物理的なストレージの差があるのかどうかは分かりませんが。 VARCHAR(max) と、例えば VARCHAR(500) をSQL Serverで使用することができます。しかし、どうやら varchar(max) と比較して varchar(8000) .

参照 本リンク (コメントとしてErwin Brandstetterによって投稿されました）。

編集 2013-09-22

bigownさんのコメントについて。

9.2以前のPostgresのバージョン（私が最初の回答を書いた時にはまだありませんでした）では、列の定義への変更は した。 はテーブル全体を書き換えます。 ここで . 9.2 以降はこのようなことはなくなり、120 万行のテーブルでカラムサイズを大きくしても 0.5 秒しかかからないことが確認されました。

Oracle の場合も同様で、大きなテーブルの varchar の欄をご覧ください。しかし、そのための参考文献を見つけることができませんでした。

MySQLの場合 マニュアルには " ほとんどの場合 ALTER TABLE は、元のテーブルの一時的なコピーを作成します。 となります。また、私自身のテストでもそれは確認されています。 ALTER TABLE 120万行のテーブル（Postgresで行ったテストと同じ）に対して、カラムのサイズを大きくするために1.5分かかりました。しかし、MySQLでは ではない は、チェック制約を使用してカラムの文字数を制限するための "ワークアラウンド"を使用します。

SQL Server の場合、これに関する明確な記述は見つかりませんでしたが、Spoon のサイズを大きくするための実行時間が短縮されました。 varchar カラム（これも先ほどの120万行の表）を見ると いいえ の書き換えが行われる。

編集 2017-01-24

SQL Serverについて、私は（少なくとも部分的に）間違っていたようだ。参照 Aaron Bertrandの回答 の宣言された長さは nvarchar または varchar カラムを使用すると、パフォーマンスに大きな差が出ます。