【入門編】外部キー制約 – Cloud Spanner

こんにちは。Cloud Spannerの世界へようこそ。
大規模なシステムを支えるこの「究極のデータベース」を学ぼうとしているあなたの姿勢、素晴らしいですね。

今回は、Spannerを語る上で避けては通れない、でも一番「親しみやすい」機能である「外部キー制約」についてお話しします。

難しい技術用語は一旦横に置いて、日常の出来事に例えながら、その「本質」を紐解いていきましょう。

—

想像してみてください。あなたは巨大な図書館の管理人です。そこには「利用者カード」の台帳と、「貸出記録」の台帳の2つがあります。

ここで問題です。もし「利用者台帳」に載っていない架空の人物が、「貸出記録」に名前を連ねていたらどうでしょう？あるいは、貸出中の本があるのに、その利用者が勝手に「利用者台帳」から消えてしまったら？

図書館の運営はめちゃくちゃになりますよね。

この「貸出記録は、必ず存在する利用者の名前でなければならない」というルールを強制するのが「外部キー制約」です。Spannerでは、この「データの整合性（＝つじつまが合っていること）」をシステムが自動的に守ってくれるのです。

—

Cloud Spannerは、世界中のユーザーが同時にアクセスしてもデータが壊れないように設計された、とてつもなく強力なデータベースです。そんなSpannerにとって、外部キー制約は「データの守護神」のようなもの。

具体的にどう守ってくれるのか、ルールを見てみましょう。

—

さて、ここからが少しだけエンジニアっぽい話です。
先ほどの図書館の例で、「利用者が退会したら、その人の貸出履歴も一緒に削除してほしい」というケースがあるかもしれません。

これを手動でやると大変ですが、Spannerには`ON DELETE CASCADE`という魔法の設定があります。

これをつけると、親となる「利用者」が消された瞬間、子である「貸出記録」も自動的に消滅します。「親が去れば、子供（紐づくデータ）も整理される」という、非常にスマートな仕組みです。

— 利用者テーブル（親）
CREATE TABLE Users (
UserId INT64 NOT NULL,
Name STRING(MAX),
) PRIMARY KEY (UserId);

— 貸出記録テーブル（子）
CREATE TABLE Loans (
LoanId INT64 NOT NULL,
UserId INT64 NOT NULL,
BookTitle STRING(MAX),

— ここが外部キー！
— UsersテーブルのUserIdと紐づけます
CONSTRAINT FK_Loans_Users FOREIGN KEY (UserId) REFERENCES Users(UserId)

— 「ON DELETE CASCADE」をつけると、
— 利用者が消えたら、その人の貸出記録も自動で消えます！
ON DELETE CASCADE
) PRIMARY KEY (LoanId);

—

世の中にはたくさんのデータベースがありますが、Spannerで外部キーを使う理由は「分散環境でもデータの正しさを一切妥協しないから」です。

普通、データベースが世界中に広がっていると、データの整合性を守るのは非常に難しいのですが、Spannerは独自の技術でそれを実現しています。この「外部キー」を適切に設定しておくことで、「大規模なのに、矛盾が一切ない美しいデータ」を保つことができるのです。

—

今回お伝えしたかったのは、以下の3点だけです。

1. 外部キーは「データのつじつま」を守るための約束事。
2. 設定しておけば、プログラムでわざわざチェックしなくてもSpannerが勝手に守ってくれる。
3. `ON DELETE CASCADE`を使えば、データの掃除も自動化できる。

これさえ理解できれば、あなたはもうSpannerのデータベース設計の第一歩を完璧に踏み出せています。

最初は難しく感じるかもしれませんが、データベースは「データの図書館」です。利用者が迷わないように、そして貸出記録が矛盾しないように整えてあげる。その優しさが、結果として最高のシステムを作るんですよ。

これからも一緒に、Spannerの深淵を覗いていきましょうね。応援しています！