DB設計時のカラム名変換テクニック｜camelCaseで事故った話

:::note ※DBの命名で事故りたくない人向けの「回避ガイド」記事です :::

結論（私の判断基準）

• DBは snake_case 一択。例外はない
• camelCase は事故る。私は事故った
• 可読性より一貫性。後から直すのは地獄

🚀 一括変換 → Case Converter

---

私がDBで事故った話

PostgreSQLで userName というカラムを作った。

CREATE TABLE users (
  userId INT,
  userName VARCHAR(100)
);

PostgreSQLは大文字を小文字に正規化する。userName は username になった。

問題はここから。アプリケーション側では userName でアクセスしようとする。見つからない。username で書き直した。

でも別のテーブルでは user_name を使っていた。username と user_name が混在。どっちがどっちか分からなくなった。

camelCase でDBを作ると、後から直すのが地獄になる。

---

なぜDBは一段厳しくすべきか

理由1：後から直せない

コードの変数名は検索置換で直せる。DBのカラム名は、マイグレーション、データ移行、アプリケーション修正が必要。

理由2：複数人で触る

DBは複数人で触る。チームの誰かが違う命名をしたら、混在する。

理由3：DBMSによって挙動が違う

DBMS	大文字の扱い
PostgreSQL	小文字に正規化
MySQL	OSによって異なる
SQLite	大文字小文字を区別

snake_case で統一すれば、DBMSの違いを気にしなくていい。

---

よくある失敗（私が見たケース）

失敗1：キャメルケースで作ってしまう

-- ❌ 環境によって動作が変わる
CREATE TABLE UserProfile (
  userId INT,
  userName VARCHAR(100)
);

失敗2：予約語と衝突

-- ❌ user, order, index などは予約語
CREATE TABLE user (
  order INT
);

users（複数形）や user_order のようにする。

---

一括変換の手順（私のやり方）

1. カラム候補をリストアップ

ユーザーID
ユーザー名
作成日時
更新日時
削除フラグ

2. 英語に翻訳

user id
user name
created at
updated at
is deleted

3. Case Converter で snake_case に変換

user_id
user_name
created_at
updated_at
is_deleted

---

命名のコツ（私のルール）

日時系

意味	カラム名
作成日時	created_at
更新日時	updated_at
削除日時	deleted_at

_at で統一。

フラグ系

意味	カラム名
削除済み	is_deleted
有効	is_active

is_ プレフィックス。

---

迷ったときの判断

迷い	私の判断
camelCase を使うか	使わない。事故る
可読性と一貫性	一貫性を取る
後から変えるか	変えない。最初から snake_case

---

この記事で解決しない場合

• FE/BEの変換を知りたい → フロントエンドとバックエンドの命名規則と変換
• 命名規則の全体像を知りたい → 命名規則の使い分け

---

DBは snake_case 一択。camelCase で事故った経験がある人なら分かる。