タイトルは、質問のほとんどを構成しています。私は何年もCHARを使用していません。現在、主キー、コードなどのために、全体に CHAR を持つデータベースをリバース エンジニアリングしています。CHAR(30) 列はどうですか?
編集：したがって、一般的な意見は、特定のことに対して完全に問題がない場合、そのCHARのようです。ただし、「これらの特定のもの」を必要としない、つまり固定長の文字列を必要としないデータベーススキーマを設計できると思います。bit、uniqueidentifier、varchar、および text 型を使用すると、適切に正規化されたスキーマでは、エンコードされた文字列値を使用した場合には得られない特定の優雅さが得られるようです。一定の長さで考えることは、攻撃を意味するものではなく、メインフレーム時代の遺物のようです (私はかつてRPG IIを学びました)。私はそれが時代遅れであると信じており、そうでないと主張する説得力のある議論を聞いていません.
コードには char(n) を、説明には varchar(m) を使用します。Char(n) は、コンテンツのサイズが変更されたときにデータを移動する必要がないため、パフォーマンスが向上するようです。
データの性質によってフィールドの長さが決まる場合は、CHARを使用します。それ以外の場合はVARCHAR。
私がよく知っているDBMSでは、CHARはVARCHARよりも処理が高速です。それらの固定サイズにより、VARCHAR では不可能な最適化が可能になります。さらに、ほとんどの行が CHAR 列に完全に、またはほぼ完全に入力される必要があると仮定すると、長さを格納する必要がないため、CHARS の場合、記憶域の要件はわずかに少なくなります。
これは、CHAR(4) よりも CHAR(30) の方が (パーセンテージで) 影響が小さくなります。
使用法に関しては、次のいずれかの場合に CHAR を使用する傾向があります。
それ以外では、VARCHAR を使用します。
値の長さが固定されている場合はCHARを使用します。たとえば、特定の固定長（たとえば13）のコードを返すアルゴリズムに基づいてコードなどを生成しています。
そうでなければ、私はVARCHARの方が良いと思いました。VARCHARを使用するもう1つの理由は、アプリケーションで値を取得するときに、その値をトリミングする必要がないことです。CHARの場合、値が列を完全に埋めているかどうかに関係なく、列の全長を取得します。それはスペースで埋められ、すべての値をトリミングすることになり、それを忘れるとエラーが発生します。
PostgreSQL の場合、ドキュメンテーションにはchar()、ストレージ スペースの点で よりも利点がないと記載されていvarchar()ます。唯一の違いは、指定された長さまで空白が埋め込まれていることです。
そうは言っても、私はまだ1文字または3文字のコードにchar(1)またはを使用しています。char(3)ストレージやパフォーマンスの利点がなくても、列に何を含める必要があるかを指定する型による明確さは価値があると思います。はい、通常、チェック制約または外部キー制約も使用します。それらの場合を除いて、私は通常、を使用するのtextではなく、そのまま使用しvarchar()ます。繰り返しますが、これはデータベース実装によって通知されます。値が十分に大きい場合、インラインからアウトオブライン ストレージに自動的に切り替わりますが、他のデータベース実装では行われません。
Char は時代遅れではありません。フィールドの長さが変化しない場合にのみ使用する必要があります。平均的なデータベースでは、これは非常に少数のフィールドであり、ほとんどが郵便番号を使用する場合に標準の 2 文字である State Abbreviations のようなコード フィールドです。ファイルの長さが可変である場合に Char を使用すると、多くのトリミングが行われ、余分な不要な作業が発生し、データベースをリファクタリングする必要があります。