web-dev-qa-db-ja.com

テキストフィールドに長さの制約を追加する方法

PostgreSQL（またはそれをサポートする他のいくつかのデータベース）を使用する場合は、character varying(NN)よりもTEXTデータ型を使用するほうがよいようです。パフォーマンスが低下することはなく、可能な最大長であるためです。フィールドを使用するビューなどに影響を与えることなく、制約を削除して再適用することで調整できます。

しかし、この制約はどのように適用されますか（SQLコード）？

sqlpostgresqlconstraints
13
Tobias

テーブルを作成すると、このようなことを行うことができます。

CREATE TABLE names (
  name text CHECK namechk (char_length(name) <= 255)
)

（namechkは制約の名前です）

同じことがALTER TABLE 例えば：

ALTER TABLE names
  ADD CONSTRAINT namechk CHECK (char_length(name) <= 255);
23
gmaliar

ここには本当に3つのことがあります。

  1. text +チェック制約、またはvarchar(N)を使用する方が良いですか？
  2. 適切なチェック制約をどのように記述しますか？
  3. 制約に名前を付けますか、それとも自動で名前を割り当てますか？

答え：

  1. varchar(N)は、スキーマを検査するとき、および他のDBから来ている開発者が何を期待するかをより明確にするでしょう。しかし、あなたが言うように、後で変更するのは難しいです。新規または変更されたチェック制約の適用は自由ではないことに注意してください。既存のすべての行を制約に対してチェックする必要があるため、大きなテーブルでは大量の読み取りが必要です。
  2. チェック制約の構文は、_CREATE TABLE_ステートメントのCONSTRAINT name CHECK (condition)（またはCHECK (condition)とPostgres自体に名前が付けられる）とALTER TABLE table_name ADD CONSTRAINT name CHECK (condition);です。 conditionは、適切な 文字列関数 を使用した式になります。 char_length(foo) <= 255。
  3. 制約の名前を追加すると、後で制約を管理する場合に非常に役立ちます。特に、柔軟性のためにこれを使用しているので、新しい長さの制約を削除して再作成するコードを作成することもできます。グラフィカルツールのみを使用している場合、これは問題ではありませんが、変更をスクリプト化できれば、複数のサーバーの管理（開発、テスト、運用コピーなど）がはるかに簡単になります。名前付き制約の場合、これはALTER TABLE foo DROP CONSTRAINT ck_bar_length; ALTER TABLE foo ADD CONSTRAINT ck_bar_length CHECK ( char_length(bar) <= 100 );のようになります。制約に名前を付けることの欠点を実際に考えることはできません。
6
IMSoP