web-dev-qa-db-ja.com

VARCHAR列に任意の長さ制限を追加する必要がありますか？

PostgreSQLのドキュメント によると、VARCHAR、VARCHAR(n)とTEXTの間にパフォーマンスの違いはありません。

nameまたはaddress列に任意の長さ制限を追加する必要がありますか？

編集：次のようなものではありません：

CHARタイプは過去の遺物であることは知っています。パフォーマンスだけでなく、Erwinのような他の長所と短所も彼の驚くべき答えで述べました。

postgresqlperformancedatatypesvarchar
41
Daniel Serodio

答えはnoです。
回避できる場合は、長さ修飾子を varchar に追加しないでください。ほとんどの場合、とにかく実際には長さの制限は必要ありません。すべての文字データに対して text を使用するだけです。一般的な文字列タイプとしてvarcharを持たないRDBMSとの互換性を維持する必要がある場合は、text（長さ修飾子なし）にしてください。

パフォーマンスはほぼ同じです-textは まれな状況では少し速い であり、長さのチェックのサイクルを節約できます。

最大長を強制するために実際にneedする場合でも、textを使用してcheck制約そのため：

ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 51);

このような制約は、テーブル定義や依存オブジェクト（ビュー、関数、外部キーなど）をいじる必要なく、いつでも変更または削除できます。

長さ修飾子は this または this または this ...のような問題を引き起こす可能性があります。

PostgreSQL 9.1は、痛みを多少軽減する新機能を導入しました。 リリースノート：

許可ALTER TABLE ... SET DATA TYPE適切な場合にテーブルの書き換えを回避する（Noah Misch、Robert Haas）

たとえば、varchar列をテキストに変換する場合に、テーブルを書き換える必要がなくなりました。ただし、varchar列の長さの制約を増やすには、テーブルの書き換えが必要です。

53
Erwin Brandstetter

長さの制限がデータを検証することを確認するための一種のチェック制約として表示された場合は、はい追加してください。実際にはnot長さの定義を使用しますが、代わりに実際のチェック制約を使用して、changeingの制限を高速化できます。

長さの制限を変更（増加）するには、_ALTER TABLE_を実行する必要があります。これには、（テーブルの再書き込みの可能性があるため）終了するまでに時間がかかる可能性があり、その間に排他テーブルロックが必要です。

チェック制約の変更（つまり、削除および再作成）は非常に簡単な操作であり、テーブルのデータを読み取るだけで行は変更されません。そのため、処理速度が大幅に向上します（つまり、排他的なテーブルロックが保持される時間が大幅に短縮されます）。

動作中、text、varchar、またはvarchar(5000)列の間で違いはありません。

12
a_horse_with_no_name

問題は、特にVARCHAR列に任意の長さ制限を追加するかどうかです

その答えは単に「いいえ」です。 varchar(max)をサポートする下位のデータベースや、varchar(255)のような規則を使用する場合のように、任意の制限を追加することを正当化できるものはありません。ただし、仕様が制限に対処している場合、特に最新バージョンのPostgreSQLでは、答えがはるかに複雑になると思います。そして、そのために、私は[〜＃〜]はい[〜＃〜]に傾くでしょう。

私の意見では、仕様で要求されている場合、制限は賢明な選択です。特に、より合理的なワークロードの場合。他に理由がない場合は、メタデータを保持します。

ここでの私の回答から、 CHARとVARCHAR（Postgres）のインデックスパフォーマンス で、メタデータの値を扱います。

意味のある可変長のテキストキーがあり、最大長が一定であると信頼できる仕様を見つけた場合は、varcharも使用します。しかし、私はその基準に合うものは何も考えられません。

2
Evan Carroll

「長い文字列はシステムによって自動的に圧縮される」と「非常に長い値もバックグラウンドテーブルに保存される」ため、VARCHARを非常に大きな文字列の保存に定期的に使用すると、パフォーマンスに多少の違いがあるようです。理論的には、これは、非常に長い文字列フィールドに対する大量のリクエストが、短い文字列フィールドに対するよりも遅くなることを意味します。名前とアドレスはあまり長くないので、おそらくこの問題に遭遇することはないでしょう。

ただし、データベースの外部でこれらの文字列をどのように使用するかによっては、システムの悪用を防ぐために実用的な制限を追加することが必要になる場合があります。たとえば、フォームのどこかに名前と住所を表示している場合、「名前」フィールドにテキストの段落全体を表示できない可能性があるため、名前の列を500などに制限することは理にかなっています。文字。

1
Edward