テーブルをつなぐ

ここまでは、ひとつの表だけを相手にしてきた。でも実際のアプリのデータベースをのぞくと、表がいくつも入っている。なぜ1つにまとめないのだろう。

貸出の記録を1つの表で持つことを考えてみよう。「誰が」「どの本を」「いつ借りたか」。会員の名前と住所と電話番号を、貸出1件ごとに書くことになる。同じ人が10回借りれば、同じ名前と住所が10回書かれる。ここで問題が起きるよ。

• 住所が変わったら、10か所すべてを直さなければならない
• 1か所直し忘れると、どちらが正しいのか分からなくなる
• 同じ情報が何度も保存されて、無駄に場所を食う

だから表を分ける。会員の情報は会員の表に1回だけ書き、貸出の表には「どの会員か」を指す印だけを置く。この印が id で、表と表をつなぐ手がかりになるよ。この分け方は、データベース設計のいちばん基本的な考え方だ。

そして分けたものを、見るときにまたつなぐ。それがこの章で学ぶ 結合 だよ。「貸出の表と会員の表を、会員 id が一致するところでつないで」と書くと、貸出の記録に会員の名前がくっついた1枚の表ができあがる。

結合には種類がある。この違いがこの章のいちばんの山場だよ。

• 両方にそろっているものだけ をつなぐやり方
• 片方は全部残して、相手がいないところは空にするやり方

たとえば「一度も借りていない会員も含めて、全会員の貸出回数を出す」には後者が要る。前者で書くと、借りたことのない人は結果から消えてしまう。「0件の人が消える」というのは集計でとてもよくある間違いなので、意識して使い分けよう。

結合は3つ以上の表にも広げられる。貸出と会員と本を全部つないで、「誰がどの本をいつ借りたか」を1枚にする。実際のアプリの画面の裏では、こういうクエリが動いているよ。

結合を書くときに面倒なのが、同じ名前のカラムが両方の表にある場合だよ。どちらの id の話をしているのか分からなくなる。そこで、表に短い別名をつけて「この表の id」と明示する書き方を覚える。ひと手間だけれど、これをやっておくと長いクエリでも読み返せるようになる。

つまずきやすいのは、つなぐ条件を書き忘れることだ。条件なしでつなぐと、片方の全行に対してもう片方の全行が組み合わさって、とんでもない行数の結果が出てくる。100行と100行で1万行だよ。結果の件数が明らかにおかしいときは、まずここを疑おう。

理解のコツをひとつ。結合は、まず1枚の大きな表ができあがると考えると分かりやすい。つないだ結果の表を思い浮かべて、そこから絞り込み、そこで集計する。頭の中で処理の順番を追いかけるより、「つないだ後の表はどんな形か」を想像するほうが早いよ。

つなぐ相手は3つ以上でもいいし、同じ表を自分自身につなぐこともできる。「この社員の上司は誰か」のように、同じ表の中で関係をたどりたいときに使う書き方だよ。少し頭がねじれるけれど、考え方はこれまでと同じだ。

この章の内容は、自分でアプリを作るときの設計にも直結する。テーブルをどう分けるかを決めるのは、アプリを作る最初の段階の仕事だよ。ここで「なぜ分けるのか」を理解しておくと、いざ自分でデータベースを設計するときに手が動く。

ここまで来ると、SQL は「表から取り出す道具」から「バラバラに保管されたデータを組み立てて答えを作る道具」に変わる。前の章で覚えた集計と組み合わせれば、答えられる問いは一気に広がるよ。