概要：ID生成の現代的アプローチ
現代のリレーショナルデータベース設計において、主キー（Primary Key）への一意な数値の割り当ては、システム整合性を担保する最も重要な要素の一つです。かつてはアプリケーション側で採番したり、データベース側のトリガーやシーケンスオブジェクトを複雑に組み合わせたりして実装していましたが、SQL標準の進化により、現在では「IDENTITYカラム」を用いるのが主流です。特にPostgreSQLやOracle、SQL Serverなどで標準化されている「GENERATED ALWAYS」および「GENERATED BY DEFAULT」という句を活用することで、データ整合性を保ちながら、開発効率とパフォーマンスを劇的に向上させることが可能です。本記事では、これら二つの指定方法の違いを深掘りし、実務で遭遇する課題に対する最適な選択基準を解説します。
詳細解説：生成句がもたらす挙動の違い
GENERATED句は、テーブル定義時にカラムの値をデータベースエンジンが自動的に管理することを宣言します。その挙動は、開発者が「手動での値指定」をどこまで許容するかによって決定的な違いが生まれます。
1. GENERATED ALWAYS AS IDENTITY
この指定は、DBエンジンによる「完全自動化」を強制します。ユーザーがINSERT文で明示的に値を指定しようとすると、データベースはエラーを返します。「整合性の守護者」として、特定のカラムには常にシステムが生成した値のみを格納したい場合に最適です。分散システムや、データ整合性が極めて重要なマスターテーブルにおいて、人為的なミスによるIDの重複や欠番を防ぐ強固なガードレールとなります。
2. GENERATED BY DEFAULT AS IDENTITY
こちらは「デフォルトの挙動は自動生成だが、明示的な指定があればそれを優先する」という柔軟なアプローチです。既存システムのデータ移行や、特定のIDを意図的に指定してテストデータを作成したい場合に非常に有効です。ただし、ユーザーが指定した値と自動生成されるシーケンス値が衝突した場合、重複エラーが発生するリスクがあるため、運用には注意が必要です。
これら二つの最大の違いは「制約の強度」にあります。ALWAYSは「システムの論理を優先」し、BY DEFAULTは「利用者の柔軟性を許容」します。どちらを選択すべきかは、対象テーブルが「マスターデータ」なのか「トランザクションデータ」なのか、あるいは「移行対象」なのかというコンテキストによって決まります。
サンプルコード：実践的なテーブル定義と挙動の確認
以下にPostgreSQLを例とした、具体的な定義方法と挙動の差異を示すコードを提示します。
-- 1. GENERATED ALWAYS の場合
CREATE TABLE users_strict (
user_id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
user_name TEXT NOT NULL
);
-- 正常なINSERT（自動採番される）
INSERT INTO users_strict (user_name) VALUES ('Taro');
-- 失敗するINSERT（ALWAYSでは明示的な値挿入を拒否する）
-- ERROR: cannot insert into column "user_id"
INSERT INTO users_strict (user_id, user_name) VALUES (100, 'Jiro');
-- 2. GENERATED BY DEFAULT の場合
CREATE TABLE users_flexible (
user_id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
user_name TEXT NOT NULL
);
-- 正常なINSERT（自動採番される）
INSERT INTO users_flexible (user_name) VALUES ('Hanako');
-- 成功するINSERT（BY DEFAULTでは手動指定が許容される）
INSERT INTO users_flexible (user_id, user_name) VALUES (999, 'Saburo');
実務アドバイス：DBAの視点から見るベストプラクティス
実務において、これらを使い分ける際には以下の5つのポイントを考慮してください。
第一に、データ移行の計画です。外部システムからデータを取り込む際、旧システムのIDを維持しなければならないケースが多々あります。この場合、GENERATED ALWAYSを選択していると、`OVERRIDING SYSTEM VALUE`句を併用する必要があります。BY DEFAULTであればそのままINSERT可能ですが、シーケンスの現在値（last_value）が古いままになり、その後の自動採番で重複が発生するリスクがあります。移行完了後には必ず`SELECT setval(…)`を用いてシーケンスを正しい値に更新してください。
第二に、パフォーマンスへの影響です。IDENTITYカラムは内部的にシーケンスを使用します。非常に高い頻度でINSERTが発生するテーブルでは、シーケンスのキャッシュ設定を調整する必要があります。デフォルトのキャッシュ値（通常1）は安全性は高いですが、高負荷環境ではボトルネックになり得ます。ただし、キャッシュを大きくしすぎると、データベース再起動時に欠番が発生する可能性があるというトレードオフを理解しておくべきです。
第三に、テーブル設計の原則です。可能な限り主キーには意味のない連番を使用すべきです。ビジネスキー（社員番号や注文番号など）を主キーにすると、仕様変更時に地獄を見ることになります。IDENTITYカラムで内部的なキーを生成し、ビジネスキーにはUNIQUE制約を付与するのが、スケーラビリティを確保する唯一の道です。
第四に、ORM（Object-Relational Mapping）との親和性です。HibernateやEntity Frameworkなどの主要なORMは、これらのIDENTITY句を適切に解釈します。しかし、ALWAYSを指定している場合にORMが「IDを明示的に指定してINSERTしようとする」設定になっているとエラーが多発します。ライブラリの設定とDBの生成句の整合性を必ず検証してください。
第五に、ドキュメント化の徹底です。なぜそのテーブルがALWAYSなのか、なぜBY DEFAULTなのか。理由をスキーマ定義書に記載しておかないと、後の運用担当者が「なぜINSERTできないのか」と混乱する原因になります。
まとめ：保守性と柔軟性のバランス
GENERATED ALWAYSおよびBY DEFAULT AS IDENTITYは、かつての手動シーケンス管理やトリガーによる採番という「悪夢のような複雑さ」からDBAを解放してくれました。
結論として、新規に作成するトランザクションテーブルには「GENERATED ALWAYS」を推奨します。これにより、データの一貫性をシステムレベルで保証でき、アプリケーション側のバグによるID衝突を未然に防ぐことができます。一方で、既存のID体系を保持する必要があるマスターテーブルや、開発・テスト環境でデータの再現性が求められる場合には「GENERATED BY DEFAULT」が適しています。
データベースの設計は、一度確定すると修正が困難です。今回紹介した生成句の特性を深く理解し、システムの要件に合致した「最も堅牢な選択」を積み重ねていくことこそが、十年先も運用し続けられるシステムを作るための第一歩となります。技術の標準化を味方につけ、よりシンプルで保守性の高いデータベース構築を目指してください。
コメント