【実務・中級編】 EXCLUDE制約 – PostgreSQL

現場でデータベースを触っていると、必ず一度は頭を悩ませるのが「重複データの制御」ですよね。

`UNIQUE`制約を貼れば済むケースなら楽勝です。でも、もしそれが「特定の期間が重なる予約を禁止したい」とか、「ある空間的な範囲が被るレコードを許したくない」といった、時間や空間の重なりに関するルールだとしたらどうでしょう？

アプリ側でトランザクションを張ってチェック……いやいや、それだとレースコンディションが怖いですよね。DBレベルでガチガチにガードしたい。そんな時にこそ、PostgreSQLの奥の手である`EXCLUDE`制約の出番です。

今日は、この「ちょっと玄人好みな制約」を実務で使いこなすための勘所を伝授します。

—

一言で言えば、「特定の演算子を使って、レコード同士の『衝突』を検知し、拒否する仕組み」です。

普通の`UNIQUE`制約は、「値が完全に一致したらNG」というルールですよね。でも`EXCLUDE`は、「指定した演算子の結果が『真（衝突している）』であればNG」という、もっと柔軟なルールを定義できます。

これを使うには、インデックス技術の「GiST（Generalized Search Tree）」の力が必要になります。つまり、単なるB-treeでは扱えないような、複雑なデータ構造の衝突判定をDBエンジンに肩代わりさせるわけです。

—

例えば、社内の会議室予約テーブルを考えてみましょう。同じ時間に複数の予約が入ったら大惨事ですよね。

CREATE TABLE room_bookings (
id SERIAL PRIMARY KEY,
room_id INT,
booking_range TSTZRANGE, — 時間範囲型（これが肝！）

— ここでEXCLUDE制約を定義
EXCLUDE USING GIST (
room_id WITH =,
booking_range WITH &&
)
);

1. `room_id WITH =`: 同じ会議室ID同士を比較します。
2. `booking_range WITH &&`: ここが魔法のスパイスです。`&&`演算子は「範囲が重なっているか」を判定します。

もし、既に「10:00〜11:00」のレコードがある状態で、同じ`room_id`に対して「10:30〜11:30」をINSERTしようとすると……PostgreSQLが「おい、その期間は重なってるぞ！」とエラーを返してくれます。

アプリ側で「予約済みエラーを表示する」というロジックを書くのは簡単ですが、DB側で物理的に挿入を拒否できるというのは、エンジニアとしての精神安定上、非常に重要なんです。

—

`EXCLUDE`制約を使うには、`btree_gist`という拡張機能が必要になることがよくあります。標準のPostgreSQLには含まれていますが、`CREATE EXTENSION`しておくのを忘れないでください。

CREATE EXTENSION IF NOT EXISTS btree_gist;

これがないと、「そんな演算子知らないよ！」とDBに怒られてしまいます。あと、もう一つ。GiSTインデックスはB-treeに比べると書き込み時のオーバーヘッドが少しあります。

「1秒間に何万件も書き込む」ような高トラフィックなテーブルに気軽に入れると、パフォーマンスのボトルネックになる可能性があることは頭の片隅に置いておいてくださいね。トレードオフを理解した上で使うのが、プロのエンジニアです。

—

`UNIQUE`制約は基本ですが、現場の複雑な要件をすべてそれで解決しようとすると、無理が生じます。`EXCLUDE`制約を使いこなせるようになると、「データの整合性はDBが守ってくれる」という確固たる自信が持てるようになります。

「アプリ側でチェックすればいいや」ではなく、「DBの機能をフル活用して堅牢なシステムを作る」。そんな設計思想を持つと、システム全体の信頼性が一段階上のレベルへ引き上がりますよ。

ぜひ次のプロジェクトのスキーマ設計で、一度検討してみてください。何か詰まったら、またいつでも聞きに来てくださいね。現場からは以上です！