Help
Tools
TermsPrivacy

© Rollpie

MySQL
06 Feb 2026

MySQL のテーブル命名規則とカラム命名規則

テーブルやカラムの命名規則は、コードの可読性と保守性に直結します。チームで開発する場合は特に重要で、統一されたルールがないと、テーブル名やカラム名がバラバラになり、クエリを書くたびに名前を調べる手間が発生します。

テーブル命名の基本方針

スネークケースを使う

MySQL はデフォルトでテーブル名の大文字小文字を区別する（Linux 環境）ため、すべて小文字のスネークケース（user_profiles）で統一するのが安全です。キャメルケース（UserProfiles）は OS によって挙動が変わるリスクがあります。

複数形を使う

テーブルはレコードの集合なので、複数形（users, orders, products）にするのが慣例です。ただし、チーム内で単数形に統一する方針もあり、どちらかに揃えることが重要です。

カラム命名の基本方針

カラム名もスネークケースが基本です。加えて、いくつかの実務的なルールを守ると、テーブル設計の可読性が大きく向上します。

-- 良い命名例
CREATE TABLE orders (
  id INT AUTO_INCREMENT PRIMARY KEY,
  user_id INT NOT NULL,              -- 外部キーは参照先テーブル名_id
  total_amount DECIMAL(10,2) NOT NULL, -- 意味が明確
  is_paid BOOLEAN NOT NULL DEFAULT FALSE, -- 真偽値は is_ / has_ プレフィックス
  created_at DATETIME NOT NULL,       -- 日時は _at サフィックス
  updated_at DATETIME NOT NULL
);

命名規則の具体的なパターン

カテゴリパターン例
主キーidid
外部キーテーブル名_iduser_id, order_id
真偽値is_ / has_is_active, has_permission
日時_atcreated_at, deleted_at

外部キーの命名で user_id のようにテーブル名を含めると、JOIN を書くときにどのテーブルを参照しているかが一目でわかります。

避けるべき命名

よくない命名

data, info, value, tmp, flag のような汎用的すぎる名前。type, status, name のような MySQL の予約語と紛らわしい名前。略語の乱用（usr_nm, prd_cd）。

望ましい命名

具体的で意味が伝わる名前。product_name, user_status, category_code のように何を表すか明確にする。多少長くなっても可読性を優先する。

MySQL の予約語（status, type, order, key など）をカラム名に使うと、クエリで毎回バッククォートで囲む必要が生じます。

-- 予約語を使うと面倒になる
SELECT `type`, `status`, `order` FROM products;

-- 予約語を避ければシンプルに書ける
SELECT product_type, product_status, sort_order FROM products;

中間テーブルの命名

多対多リレーションの中間テーブルは、関連する2つのテーブル名をアルファベット順に結合するパターンが一般的です。

-- users と roles の中間テーブル
CREATE TABLE role_user (
  role_id INT NOT NULL,
  user_id INT NOT NULL,
  PRIMARY KEY (role_id, user_id)
);

-- posts と tags の中間テーブル
CREATE TABLE post_tag (
  post_id INT NOT NULL,
  tag_id INT NOT NULL,
  PRIMARY KEY (post_id, tag_id)
);

Laravel のような ORM フレームワークでは、この「アルファベット順＋単数形」の命名規則がデフォルトになっています。フレームワークの規約に合わせると、設定コードの記述量が減って楽になります。

プレフィックスの是非

テーブル名にプレフィックスを付ける（tbl_users, m_categories）慣習は、現代の開発ではあまり推奨されません。スキーマやデータベースで名前空間を分離できるため、テーブル名を冗長にする必要がないためです。ただし、WordPress のように wp_ プレフィックスが慣例になっているシステムもあるため、プロジェクトの方針に従いましょう。命名規則は「正解」があるわけではなく、チーム全員が一貫して守れることが最も重要です。

3views