はじめに

データベースを設計するとき、「このカラム名、どうしよう…」と悩んだ経験はありませんか？

users と user、created_at と create_date。チーム内で命名がバラバラだと、コードは読みにくくなり、思わぬバグの原因にもなりかねません。

そんな悩みを一発で解決するために、多くの現場で採用されている「分かりやすく、一貫性のある」命名規則を一枚のチートシートにまとめました。

良い例（Good）と悪い例（Bad）を比較しているので、何が良くて何がダメなのかが一目瞭然です。迷った時にいつでも見返せるように、この記事をブックマークしておくのがおすすめです！

命名規則の良い例・悪い例の比較

この表は、理想的な命名規則と、現場でやりがちな「悪い例」を具体的に比較しています。

対象	命名規則 / 説明	良い例 (Good)	悪い例 (Bad)
全体	英語の小文字 + スネークケース	`user_name` `order_details`	`userName` (キャメルケース) `UserName` (パスカルケース) `ユーザー名` (日本語)
テーブル名	複数形にする	`users` `products`	`user` (単数形) `tbl_users` (冗長な接頭辞)
カラム名	単数形にする	`email` `title`	`emails` (複数形) `product_title` (冗長)
主キー (PK)	シンプルに `id` とする	`id`	`user_id` (テーブル内では冗長) `pk_id` (意味のない接頭辞)
外部キー (FK)	`{参照先テーブル単数形}_id`	`user_id` (usersテーブルを参照)	`users_id` (参照先が複数形) `fk_user` (抽象的)
日時 (Timestamp)	接尾辞に `_at` を付ける	`created_at` `updated_at`	`create_date` (一貫性がない) `update_time`
日付 (Date)	接尾辞に `_on` を付ける	`published_on` `sent_on`	`publish_date` (一貫性がない) `send_day`
真偽値 (Boolean)	接頭辞 `is_`, `has_`, `can_`	`is_active` `has_license`	`active` (真偽値か不明) `flag` (曖昧)
種類 / 区分	接尾辞 `_type`, `_category`	`user_type` `product_category`	`type` (何のタイプか不明) `category`
状態 / ステータス	接尾辞 `_status`	`payment_status` `shipping_status`	`status` (何のステータスか不明) `state`

特に避けるべき代表的なアンチパターンがこちらです。これらを意識するだけでも、データベースの質は格段に上がります。

対象	命名規則 / 説明	良い例 (Good)	悪い例 (Bad)
① 曖昧な名前	文脈がないと意味が分からない名前は避け、より具体的に記述する。	`user_profile_data` `is_enabled_flag` `item_name`	`data` `flag` `item` `value`
② 過度な省略	初見で理解できない省略は避ける。 (id, max, minなど一般的なものはOK)	`user_name` `created_at` `description`	`usr_nm` `crt_dt` `desc`
③ SQL予約語の使用	エラーの原因になるため、そのまま使わない。別の単語を付け加える。	`order_summary` `user_group` `selected_item`	`order` `group` `select` `user`

もちろん、これが唯一絶対のルールではありません。しかし、このチートシートをベースにチーム内でルールを統一するだけで、コードの可読性とメンテナンス性は劇的に向上するはずです。

ぜひ、このチートシートをプロジェクトのコーディング規約に貼り付けたり、チームメンバーと共有したりして、活用いただけると幸いです！