【DB/Table設計】DBのTableのプロパティ名は、キャメルケースとスネークケースどちらがいいか？

DBのTableのプロパティ名は、キャメルケースとスネークケースどちらがいいか？

結論（先に要点）

• DB には snake_case の列名を推奨

  • SQL スタンダードとの相性が良く、引用符を付けずに済むため移植性が高い
  • PostgreSQL では未引用識別子が自動で小文字化されるので camelCase は避けたほうが無難

• アプリケーションコード側では camelCase（JavaScript/TypeScript なら）

  • OR マッパー（Prisma、TypeORM など）で自動変換 or エイリアス指定すれば違和感なく使える

• どうしても camelCase を DB に使う場合は 常にダブルクォートで囲む など厳格運用が必要

camelCase と snake_case の比較

推奨パターン（PostgreSQL + TypeScript の例）

-- DB スキーマ
CREATE TABLE users (
  id            BIGSERIAL PRIMARY KEY,
  email         VARCHAR(255) NOT NULL UNIQUE,
  created_at    TIMESTAMP NOT NULL DEFAULT NOW()
);

// Prisma schema
model User {
  id         BigInt    @id @default(autoincrement())
  email      String    @unique
  createdAt  DateTime  @map("created_at") // アプリ側では camelCase で扱える
}

• DB を snake_case にしておくと、Prisma の @map や TypeORM の name オプションで簡単に camelCase にマッピングできます。
• 逆に DB が camelCase の場合、毎回引用符付きで書くか ORM 任せにする必要があります。

どうしても camelCase を DB に使いたい場合の留意点

1. 全テーブル・列を必ず "CamelCase" のように引用

   • 方針を徹底しないと、未引用→自動小文字化→クエリ失敗という事故が発生します。

2. マイグレーションスクリプトもツール任せにしない

   • SQL ファイルを手で確認し、引用漏れがないか CI で検証。

3. ローワーキャメル（userId）かパスカル（UserId）かを決める

   • 両者が混在するとさらに可搬性が下がるので要注意。

運用ルールを決めるときのチェックリスト

• ターゲット DB の仕様（大小文字感度・予約語など）
• ORM／クエリビルダの機能（自動マッピング可否）
• 既存資産との整合（社内で使われている他の DB 名付け規約）
• 多言語連携の有無（Java/Kotlin など別言語が同じ DB を触る場合）
• チーム習熟度（SQL に不慣れなら snake_case が学習コスト低い）

DB層/App層で使い分ける📝

“列名は snake_case、コードは camelCase”

これが現場で最もトラブルが少ない組み合わせです。
OR マッパーの命名変換機能を活用して、DB とアプリそれぞれの文化に合わせるのがベストプラクティスと言えます。

まとめ

データベースのカラム名には、通常スネークケース（snake_case）が推奨されます！
理由としては、SQLの識別子がDBによって挙動が違うケースセンシティブであり、互換性の面で有利だからです。
また、キャメルケース（camelCase）は、SQLで引用符を使う必要があり絡むことがあります。

ただし、ORM（オブジェクト関係マッピング）を利用する際は、データベース内でスネークケース、アプリケーションでキャメルケースを使うというのが一般的な慣習です。

Prismaで、Table名もスネークケースにするには？

Prisma で テーブル名を snake_case にする方法

1. @@map 属性を付ける

Prisma Schema の モデル定義の末尾に @@map("snake_case_name") を書くと、生成される SQL の テーブル名だけを snake_case にできます。アプリ側（Prisma Client）では PascalCase / camelCase のまま呼び出せるのでコードの書き味を保てます。

model UserAccount {
  id         BigInt   @id @default(autoincrement())
  email      String   @unique
  createdAt  DateTime @default(now())

  @@map("user_account")   // ← 実 DB では user_account というテーブルになる
}

• マイグレーションを作成すると、CREATE TABLE "user_account" … が生成されます。
• Prisma Client では prisma.userAccount.findUnique() のように モデル名ベースで呼び出します。

@map は 列名用、@@map は テーブル／ビュー／enum 名用です。(Prisma)

2. 既存 DB を introspection した場合

prisma db pull を実行すると、DB 側が snake_case でも 自動で @@map を付けて PascalCase のモデルに変換してくれます。何も変更しなくてもクライアントコードは PascalCase で扱えます。

3. 多対多の中間テーブル名を変えたい場合

Prisma v5 以降は次のように 明示的なリレーションモデルを書くと、中間テーブルにも @@map が使えます。

model PostTag {
  post   Post @relation(fields: [postId], references: [id])
  tag    Tag  @relation(fields: [tagId],  references: [id])
  postId Int
  tagId  Int

  @@id([postId, tagId])
  @@map("post_tag")   // 中間テーブルも snake_case
}

4. グローバル設定はまだ無い

2025-05 時点では スキーマ全体を一括で snake_case に変換する公式フラグは存在しません。モデルごとに @@map を書くか、外部ツール（CLI スクリプトなど）でスキーマを自動加工する方法が一般的です。(GitHub)

まとめ

ポイント: コードは PascalCase / camelCase、DB は snake_case にして @@map / @map で橋渡しするのが最小コストで実運用しやすいパターンです。