1. 導入：なぜPRIMARY KEY制約が重要なのか
データベース設計において、PRIMARY KEY（主キー）はテーブル内の各レコードを一意に識別するための「指紋」のような存在です。実務では、この制約を適切に設定していないと、データが重複したり、特定のレコードをピンポイントで更新・削除できなくなったりと、深刻なデータ不整合を招きます。また、主キーには自動的にインデックスが作成されるため、クエリの検索性能を担保する上でも非常に重要な役割を果たします。
2. 基礎知識：PRIMARY KEYの特性
PRIMARY KEY制約を設定すると、以下の2つのルールが強制されます。
・一意性（UNIQUE）: 同じ値を持つレコードを複数登録できない。
・非NULL（NOT NULL）: 未入力（NULL）を許容しない。
これらにより、テーブル内のすべての行を「確実に特定」できる状態が保証されます。また、1つのテーブルにつきPRIMARY KEYは1つ（複数のカラムを組み合わせた複合主キーを含む）しか設定できません。
3. 実装/解決策：現場で使い分ける設計手法
主キーの設計には大きく分けて2つのパターンがあります。
・サロゲートキー（代理キー）: 業務的な意味を持たない連番（IDなど）を主キーにする方法。変更に強く、実務で最も推奨されます。
・ナチュラルキー（自然キー）: コードや社員番号など、業務データそのものを主キーにする方法。一見分かりやすいですが、将来的な仕様変更で値が変わる可能性があるため注意が必要です。
4. サンプルプログラム：複合主キーの定義例
以下は、複数のカラムを組み合わせて一意性を担保する「複合主キー」の定義例です。
— 従業員IDだけでなく、所属部署との組み合わせで主キーを構成する例
CREATE TABLE employee_department (
emp_id INTEGER,
dept_code VARCHAR(10),
join_date DATE,
— 複数のカラムをPRIMARY KEYに指定することで「複合主キー」となる
PRIMARY KEY (emp_id, dept_code)
);
— 正常なデータ挿入
INSERT INTO employee_department VALUES (101, ‘D01’, ‘2023-04-01’);
— 重複した組み合わせ（101, D01）を追加しようとするとエラーが発生する
— ERROR: 重複キーが一意性制約に違反しています
INSERT INTO employee_department VALUES (101, ‘D01’, ‘2024-04-01’);
5. 応用・注意点：現場で陥りやすいバグと回避策
・インデックスの肥大化: 複合主キーでカラムを増やしすぎると、インデックスサイズが大きくなり、メモリやディスクを圧迫します。主キーはできるだけシンプルに、かつデータ型のサイズが小さいもの（INTEGER型など）を選ぶのが定石です。
・NULLの罠: 複合主キーを構成するカラムには、いずれもNOT NULL制約が自動付与されます。外部システムからの連携で、意図せずNULLが混入するようなカラムを主キーに含めないよう、データ設計時に十分注意してください。
・パフォーマンスの確認: 運用中に遅延が発生した際は、psqlの「\d テーブル名」コマンドでインデックスが正しく効いているか確認しましょう。主キーがあるだけで、検索速度は劇的に向上します。
適切なPRIMARY KEY設計は、後のアプリケーション修正コストを大幅に下げます。ぜひ、設計段階で「このテーブルの行を一意に特定する最小単位は何か？」を常に自問自答してみてください。
コメント