表計算一枚では足りない理由
漫画喫茶を営んでいるとしよう。会員名簿が要り、所蔵する漫画の一覧が要り、誰がいつ何を借りて返したかの記録が要る。
これを表計算一枚に全部入れられるだろうか。無理をすれば入るが、すぐ使えなくなる。左の区画は会員、真ん中は本、下の何行目からは貸出記録、といった具合では管理できない。
だからシートを分ける。会員は会員シート、本は本シート、貸出記録はまた別のシートに置く。そしてお互いをつなぐ。この会員がこの本を借りたという事実は、二つのシートをつなぐ形で書かれる。
リレーショナルデータベースがまさにこの形だ。名前にあるリレーショナルという語が、このつながりを指している。
テーブル・行・列、そしてキー
表一つをテーブルという。表計算のシート一枚にあたる。
最上行には列名が入る。ID、名前、連絡先といったものだ。その下には一行ずつデータが積まれる。会員一人が一行、本一冊が一行である。
次につなぎ方だ。会員表のある会員の ID が 1 だとする。貸出記録表に会員 ID を書く列を置いてそこに 1 と書けば、その貸出がこの会員のものだという事実が表現される。こうして別の表を指す値を外部キーという。
そして各行を一意に指す値が要る。会員表の ID のように重複しない値だ。これを主キーという。外部キーは結局、別の表の主キーを指している。
members books loans
───────────── ───────────── ──────────────────────
id name id title id member_id book_id
1 ミンス 7 スラムダンク1 1 1 7
2 ソヨン 8 スラムダンク2 2 1 8
3 2 7
loans.member_id は members.id を指す外部キー
loans.book_id は books.id を指す外部キースキーマは硬い代わりに安定している
表の形をスキーマという。どの列があるか、各列にどんな形の値が入りうるかをあらかじめ決めておくものだ。
決めることはかなり細かい。この列は数字だけ、あの列は文字を何字まで、この値は空であってはならず、あの値は互いに重複してはならない、という具合である。
硬い。あとから列を足したり形を変えたりするには、すでに溜まったデータに手を入れなければならない。代わりに安定している。決めた形に合わない値は最初から入れない。
だから、ある表をいくつに分けどうつなぐかを決めること自体が専門領域だ。サービスが大きくなればこの設計だけを担う人を置く。同じデータでも分け方によって、後で抱えきれるかどうかが分かれる。
クエリ、そしてリレーショナルでないもの
データベースに何かをさせる文をクエリという。値を取り出す、入れる、直す、消すという仕事をこの文で命じる。
SQL が名前に付く製品はすべてこの文を使う。PostgreSQL もその一つで、バイブコーディングの案件でよく出会う。文の見た目はおおむね似ているので、一つ覚えれば他の製品でも通じる。
近ごろはクエリをコードの中に直接書くことは減った。間で代わりに組み立ててくれる道具がよく整っており、前回見たバックエンドのコードにデータの形だけ定義しておけばクエリはそちらが書く。
リレーショナルでない種類もある。各項目を丸ごと一つの文書として保存する文書型は、形がよく変わるデータに使う。何と何がつながっているかだけを保存するグラフ型もある。ただしウェブサービスの既定は依然リレーショナルだ。次回はこの表に入れないもの、画像や動画をどこに置くかを見る。
SELECT title FROM books WHERE id = 7;
INSERT INTO loans (member_id, book_id) VALUES (1, 7);
UPDATE members SET name = 'ミンス' WHERE id = 1;
DELETE FROM loans WHERE id = 3;