DBテーブル・カラム名の命名規則チートシート

はじめに

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

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

おわりに

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

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