第03回: 主キー・外部キーの基本 — データの「つながり」を壊さないために

(Updated: )
1 min read

章: 第1章: 基礎と環境構築

外部キーなしで設計すると、何が起きるのか？

ユーザーを削除したのに、そのユーザーの投稿が残り続ける。存在しないユーザーIDを持つ注文レコードが生まれる。外部キー制約がないDBは、アプリ側のバグがそのままデータ破損につながります。

主キーと外部キーを正しく使うと、DB自身がデータの一貫性を守ってくれます。 アプリ側の防御コードを減らし、設計の信頼性を上げる基本スキルです。

主キー vs 外部キーの役割を整理する

外部キーは「参照整合性」を保証する仕組みです。「このテーブルのこのカラムは、あのテーブルのあのカラムに必ず存在する値しか入れない」というルールをDB側で強制します。

ON DELETE オプションの比較

オプション 挙動 向いているケース
CASCADE 親レコード削除時に子も自動削除 投稿とそのコメントなど、親なしでは意味がないデータ
RESTRICT 子が存在する場合は親の削除を拒否 ユーザーと注文など、履歴を残したいケース
SET NULL 親削除時に外部キー列をNULLにする 紐付けが任意な関係（担当者が退職しても案件は残す）

チェックポイント: CASCADE は便利ですが、意図しない大量削除が起きるリスクがあります。本番では RESTRICT を基本とし、削除処理はアプリ側で明示的に制御するほうが安全なケースが多いです。

実際のコードのサンプル


CREATE TABLE posts (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  user_id BIGINT UNSIGNED NOT NULL,
  title VARCHAR(255) NOT NULL,
  body TEXT NOT NULL,
  CONSTRAINT fk_posts_user
    FOREIGN KEY (user_id) REFERENCES users(id)
    ON DELETE CASCADE
);

まとめ & 次のステップ

  • 主キーはテーブル内で一意にレコードを識別するカラム（BIGINT UNSIGNED AUTO_INCREMENT が定番）
  • 外部キーはテーブル間の参照整合性をDB側で強制する仕組み
  • ON DELETE CASCADE は親削除で子も消える。RESTRICT は子がいると親削除を拒否する
  • 外部キーカラムには自動でインデックスが付くため、JOIN性能にも貢献する

次回は 「INSERT/UPDATE/DELETEの基本」 を学びます。データを安全に操作するための基本CRUDを、ミスを防ぐ書き方とセットで確認します。

Related Articles