テキスト型データ: CHAR, VARCHAR, TEXT

PostgreSQLでテキストデータを扱うとき、主役は3つあるよ：CHAR、VARCHAR、TEXT。それぞれ特徴やメリット、クセがあるから、順番に見ていこう！

CHAR(n)

CHAR、つまりcharacterは、固定長の文字列nを表すよ。もしデータの文字数が指定より少なかったら、自動的にスペースで埋められる。

例:

この型は、すべての文字列が同じ長さである必要がある場合（例えば、コードやバーコード、固定長のIDなど）に便利だよ。

でも、可変長テキストを扱う場合は、余計なスペースが無駄にDBの容量を食うだけ。

VARCHAR(n)

VARCHAR、つまりvariable characterは、最大n文字までの可変長文字列を保存するための型だよ。

例:

この型は実際のテキストだけを保存するから、容量を効率よく使える。ただし、長さ制限を指定しなきゃいけないのがデメリット。もし文字列が制限を超えたら、DBがエラーを返すよ。

TEXT

TEXTは、長さ制限のない文字列型。どれだけ長くなってもOKだから、テキストがどこまで大きくなるかわからないときによく使う。

例:

メリット: どんな長さのテキストでも保存できるから、制限を気にしなくていい。

デメリット: 制限がない分、テキストデータが膨れ上がるとDBの効率が悪くなることもある。

テキスト型データの比較

テキストを扱うとき、どの型がケースに合ってるか理解するのが大事。CHAR、VARCHAR、TEXTの主な違いはこんな感じ：

実践的な使い方例

じゃあ、実際にどう使うか見てみよう！

例1: 固定長コードにCHARを使う

例えば、ISO 3166-1 alpha-3規格の都市コードをDBに保存したいとする。各コードは必ず3文字だよ。

ここではCHAR(3)がピッタリ。都市のISOコードは必ず3文字だからね。

例2: ユーザー名にVARCHARを使う

ユーザー名は可変長だけど、50文字を超えることはまずないよね。こういうときはVARCHARが最適！

この場合、VARCHARなら実際の文字数分だけ保存されるから、容量の節約になるよ。

例3: 説明文の保存にTEXTを使う

例えばブログで、各投稿に長い説明文を保存したいときはTEXTがベスト！

テキストの長さが事前にわからないなら、TEXTが最適だね。

4. 追加の注意点と落とし穴

テキスト型データを扱うとき、よくあるミスを避けるために知っておきたいポイントがいくつかあるよ。

問題: CHARはスペースを追加する

CHAR型のフィールドでスペースを考慮せずに文字列を比較すると、思わぬ結果になることがある。

SELECT * FROM cities WHERE iso_code = 'NYC';
-- スペースを除去しないと何も返らない

解決方法: スペースを消すにはTRIM()関数を使おう。

SELECT * FROM cities WHERE TRIM(iso_code) = 'NYC';

問題: VARCHARの長さ制限でエラーになることがある

VARCHAR型のフィールドに最大長を超える文字列を入れようとすると、DBがエラーを返すよ。

INSERT INTO users (username, email) VALUES ('A_username_that_is_too_long_for_field', 'test@example.com');
-- エラー

解決方法: 長さ制限（n）が実際のニーズに合ってるか確認しよう。もしくは制限を避けたいならTEXTを使おう。

問題: TEXTはDBを膨らませる可能性がある

TEXTは無制限にデータを保存できるから、テーブルが無駄に大きくなったり、インデックスが重くなったりすることがある。

回避方法: TEXT型カラムをガンガンインデックス化したいなら、制限付きのVARCHARを使うのもアリ。