導入
データベース設計において、テーブル内の各行を「一意に識別する」ことは最も重要な責務の一つです。もし主キーが定義されていないテーブルが存在すれば、同じデータが重複して登録されたり、特定の行をピンポイントで修正・削除することが困難になったりします。本記事では、MariaDB環境を想定し、PRIMARY KEY制約を活用してデータの整合性を守るための基礎と実践テクニックを解説します。
基礎知識
PRIMARY KEY（主キー）とは、テーブルの中で各レコードを特定するために設定する識別子です。この制約を付与したカラムには、以下の2つの大きな特徴が備わります。
1. 一意性（UNIQUE）: 同じテーブル内で重複した値は許されません。
2. 非NULL性（NOT NULL）: 値を空（NULL）にすることはできません。
これらにより、主キーを指定するだけで「必ず存在し、かつ重複しない」というデータ品質を強制できます。また、主キーには自動的にインデックスが作成されるため、特定のレコードを検索する際のパフォーマンス向上も期待できます。
実装/解決策
主キーの設定には、カラム定義時に指定する方法と、テーブル定義の最後にまとめて定義する方法があります。特に後者は、複数のカラムを組み合わせて主キーを作成する「複合主キー」を定義する際に必須となります。
サンプルプログラム
以下のSQLは、単一カラムの主キーと、複数カラムを組み合わせた複合主キーの作成例です。
— 1. 単一カラムでの主キー設定
— idカラムを主キーに設定します
CREATE TABLE users (
id INT PRIMARY KEY,
username VARCHAR(50) NOT NULL
);
— 2. 複合主キーの設定
— 注文テーブルなどで、注文IDと商品IDの組み合わせを一意にしたい場合
CREATE TABLE order_items (
order_id INT,
product_id INT,
quantity INT,
— カラム定義の最後で組み合わせを指定
PRIMARY KEY (order_id, product_id)
);
— データ挿入テスト
INSERT INTO users VALUES (1, ‘Alice’);
— 次の行はidが重複するためエラーになります
— INSERT INTO users VALUES (1, ‘Bob’);
INSERT INTO order_items VALUES (101, 1, 2);
— order_idとproduct_idの組み合わせが同じ場合はエラーとなります
— INSERT INTO order_items VALUES (101, 1, 5);
応用・注意点
現場で主キーを設計する際に注意すべきポイントが3つあります。
1. 不変性（Immutable）: 主キーの値は、原則として「一度決めたら変わらないもの」を選ぶのが理想です。例えば、メールアドレスを主キーにすると、変更が発生した際に連鎖的に他のテーブルの外部キーまで更新が必要になり、管理コストが跳ね上がります。
2. サロゲートキーの検討: ビジネス上の値（社員番号やISBNなど）を主キーにするのではなく、システム側で自動採番される連番（AUTO_INCREMENT）を主キーにする「サロゲートキー（代理キー）」の利用を推奨します。これにより、外部からの仕様変更の影響を受けにくくなります。
3. 複合主キーの複雑さ: 複合主キーは便利ですが、外部キーとして他テーブルから参照する際にカラム数が多くなり、クエリの記述が煩雑になります。基本的にはシンプルな単一カラムの主キーを推奨し、複合キーは「特定の組み合わせで重複させたくない」という制約目的で活用しましょう。
正しい主キー設計は、後々の運用負荷を劇的に下げます。設計段階で「この行を確実に特定できるか？」を常に自問自答することが、堅牢なデータベース構築への近道です。
コメント