こんにちは！データベースの世界へようこそ。
PostgreSQLを触り始めると、まず最初に「あれ、文字を入れる箱（型）ってどれを選べばいいの？」と迷う瞬間が必ず訪れますよね。`char(n)`、`varchar(n)`、そして`text`。名前が似ているようでいて、実は中身の振る舞いは全然違うんです。
今日は、この「文字型の選び方」について、ちょっと身近な例え話を交えながら、データベースエンジニアの視点で「本当のところ」をお話ししますね。
—
1. 3つの文字型を「箱」で例えてみよう
データベースの型を選ぶのは、引っ越しで使う「段ボール箱」を選ぶのとそっくりです。
`char(n)`：決まったサイズの「固定ケース」
`char(10)`と決めたら、中身が1文字でも10文字でも、必ず10文字分のスペースを確保します。
- 例え: 「必ず10個入るよう仕切られたトレイ」。
- 特徴: どんなにスカスカでも10個分を占領します。今のPostgreSQLでは、実はあまり出番がありません。「昔の古いシステムとの互換性」のために残っているようなものだと思ってOKです。
`varchar(n)`：伸縮自在の「サイズ指定袋」
`varchar(10)`と決めたら、最大10文字までは入るけど、3文字しか入っていなければ3文字分だけを使います。
- 例え: 「10個まで入る、中身に合わせて縮むビニール袋」。
- 特徴: 「最大10文字まで」というルールを守りつつ、無駄を省けるのが魅力です。
`text`：なんでも入る「無限の広さ」
`text`型には文字数制限がありません。
- 例え: 「何でも入る大きなバックパック」。
- 特徴: 最も柔軟です。実はPostgreSQLにおいて、`varchar(n)`と`text`の性能差はほとんどありません。
—
2. なぜ `text` 型が最強と言われるのか？
昔のデータベース（例えばMySQLの古いバージョンなど）では、`varchar`の方が`text`より圧倒的に速いという時代がありました。でも、PostgreSQLはちょっと違うんです。
PostgreSQLの設計思想では、`varchar(n)`も`text`も、内部的にはほぼ同じ扱いをしています。
それなら、制限を設ける意味はあるのでしょうか？
実は、`varchar(10)`のように長さを決めておく最大のメリットは、パフォーマンスではなく「データの整合性（ルール）」にあります。
- 「電話番号は絶対11桁！」
- 「郵便番号は7桁！」
このように、アプリケーション側で「これ以上は入ってはいけない」というルールを、データベースの設計段階で明示できるのが`varchar`の優しさなんです。逆に、日記の本文やコメント欄のような「長さが読めないもの」には、迷わず`text`を使ってあげてください。
—
3. ストレージとパフォーマンスの「意外な落とし穴」
初心者の頃、「`char(n)`の方がメモリを固定確保するから速いんじゃない？」と思うかもしれません。でも、現代のPostgreSQLにおいて、その差を気にする必要はほとんどありません。
むしろ、以下の2点に注意するだけで、あなたのデータベースはずっと快適になります。
- 無駄な制限を避ける: `varchar(5)`とか`varchar(10)`を多用しすぎると、将来「あと1文字増やしたい！」という時に、テーブル全体を変更（ALTER TABLE）する手間が発生します。変更には時間がかかるので、少し余裕を持って長さを設定しておくのがエンジニアの知恵です。
- インデックスを意識する: 検索の速さは「型」よりも「インデックスを貼っているか」で決まります。検索によく使うカラムなら、型を気にするよりも、ちゃんとインデックスを設計してあげる方が100倍効果的ですよ。
—
まとめ：結局どれを選べばいいの？
迷っているあなたへ、私からのアドバイスです。
1. 長さが厳密に決まっているもの（郵便番号、県コード、性別フラグなど）
→ `varchar(n)` でルールをしっかり決めておく。
2. 長さが読めないもの、長い文章（ブログの本文、メッセージ、住所など）
→ 迷わず `text` を選ぶ。
3. `char(n)` は使う？
→ 基本的に忘れて大丈夫です。
データベース設計は、いわば「整理整頓」です。過剰に気にしすぎず、かといって雑にもせず。まずは「何を入れるための箱かな？」と想像するところから始めてみてくださいね。
皆さんのテーブルが、今日も軽快に動きますように！また次回の記事でお会いしましょう。
コメント