タイトルがかなりフレームになっています。私はCHARを何年も使っていません。今は、主キー、コードなどのために、CHARを持つデータベースをリバースエンジニアリングしています。 CHAR（30）列はどうですか？SQLのCHARデータ型は廃止されましたか？あなたはいつそれを使いますか？
編集： したがって、一般的な意見は、特定のものについては完全に罰金であると思われます。しかし、私は、「これらの特定のもの」を必要としないデータベーススキーマを設計でき、固定長の文字列を必要としないと考えています。 bit、uniqueidentifier、varchar、およびtext型では、正規化されたスキーマでは、エンコードされた文字列値を使用するときに得られない優雅さが得られるようです。固定長で考えると、犯罪ではなく、メインフレームの時代の遺物であるように思えます（私は一度自分自身でRPG IIを学びました）。私はそれが時代遅れだと信じて、そうでないと主張する説得的な議論を聞いていない。
データの性質によってフィールドの長さが決まるところでは、私はCHARを使用します。それ以外の場合はVARCHAR
CHARは、私がよく知っているDBMSのVARCHARよりも処理が高速です。固定サイズのため、VARCHARでは不可能な最適化が可能です。さらに、ほとんどの行がCHAR列を完全に、またはほぼ完全に満たす必要があると仮定して、長さを保管する必要がないため、記憶域要件はCHARSではわずかです。
これはCHAR（4）よりもCHAR（30）の方が影響が少なくなります。使用方法については
、私は時にどちらかの文字を使用する傾向がある：
他のところでは、私はVARCHARを使用します。
コードにはchar（n）、説明にはvarchar（m）を使用します。 Char（n）は、コンテンツのサイズが変化したときにデータを移動する必要がないため、パフォーマンスが向上するようです。
値の長さが固定の場合はCHARを使用します。たとえば、特定の固定長のコードを返すアルゴリズムを基にしてコードなどを生成しています。
それ以外の場合は、VARCHARが優れています。 VARCHARを使用するもう一つの理由は、アプリケーションで値を取り戻すときに、その値をトリムする必要がないということです。 CHARの場合、値が完全に満たされているかどうかにかかわらず、列の全長が取得されます。スペースでいっぱいになると、すべての値を切り捨てることになり、それを忘れるとエラーにつながります。
Charは廃止されていません。フィールドの長さが決して変化しない場合にのみ使用してください。平均的なデータベースでは、郵便番号を使用する場合、標準の2文字のState Abbreviationsのようなコードフィールドのほとんどがほとんどフィールドになりません。ファイル長を可変にすることができるCharを使用すると、多くのトリミングが行われ、余分な不要な作業であり、データベースをリファクタリングする必要があります。
PostgreSQLの場合、char()はvarchar()を超える記憶領域に利点がありません。唯一の違いは、指定された長さに空白で埋められていることです。
1文字または3文字のコードにはまだchar(1)またはchar(3)を使用しています。ストレージやパフォーマンス上の利点がない場合でも、列に含めるべきものを指定するタイプによる明快さは価値を提供すると私は考える。そして、私は通常、チェック制約や外部キー制約も使用します。これらの場合を除いて、私は一般にvarchar()を使用するのではなく、textと固執します。この場合も、データベース実装によって通知されます。データベース実装は、値が十分に大きい場合はインラインからアウトオブラインのストレージに自動的に切り替わり、他のデータベース実装ではそうではありません。
そうですね、私の主張は次のようなものです。私自身、それを紹介していない限り、それ以上の性質のデータは表示されません。 – cdonner
@cdonner電話番号、郵便番号、可変長ではない州略語など、多くの共通フィールドがあります。また、シリアル番号、部門番号、内線番号、サイトID、店舗番号などの内部コードやものがある可能性があります。フィールドは変数ではなく、CHARはうまく動作し、最適な選択肢になります。 – Pete