付録D ORマッパー（ORM）入門 — SQLを書かずにデータを扱う道具
📖 このページのゴール：「ORM」という道具が何なのか、そして本編で使った Supabase クライアントとSQLがどうつながっているのかを知る。 ← 目次・はじめにへもどる
本編の第3章以降では、supabase.from('tweets').select()... のような書き方でデータベースを操作してきました。あれは実は SQLを直接書かないための道具の一種です。その正体である「ORM」を、ここでのぞいてみます。
🤔 ORMって何？（🟢 基礎）
ORM（オーアールエム、Object-Relational Mapper）とは、SQL文を書く代わりに、プログラムのオブジェクトやメソッドでデータベースを操作する道具です。select * from ... のようなSQLの文字列を、自分で書かずに済みます。
代表的なものを並べておきます（名前だけ覚えれば十分）。
- Prisma（プリズマ） / Drizzle（ドリズル） … JavaScript・TypeScript の世界でよく使われるORM。
- SQLAlchemy（エスキューエル・アルケミー） … Python の定番ORM。
- ActiveRecord（アクティブレコード） … Ruby on Rails に付いているORM。
そして大事なこと。本編で使った Supabase クライアントも、ORMに近い「書きやすい言い方」です。つまりみなさんは、知らないうちにORM風の道具をすでに使っていたわけです。
🗣 たとえ話：翻訳機ごしの注文 データベースは「SQL」という外国語しか話せません。SQLを直接書くのは、その外国語で店員に直接注文するようなもの。ORMを使うのは、翻訳機ごしに母国語で注文するようなもの。最後に翻訳機が外国語（SQL）へ変換してくれるので、伝わる内容は同じです。
🛠 同じことを3つの書き方で
「user_id が自分のツイートを取り出す」という同じ仕事を、3通りの言い方で書いてみます。まずは生のSQL。
-- SQL：データベースに直接話しかける言い方
select * from tweets where user_id = $1;
「tweets 表から、user_id（持ち主）が $1（ログイン中の人のID）と一致する行を全部ちょうだい」という意味です（$1 は値の差し込み口。詳しくは付録C）。
次に、これをORMで書くとこうなります。
// ORM（Prisma のイメージ）：オブジェクトとメソッドで言う
prisma.tweet.findMany({ where: { userId } });
// Supabaseクライアント（本編で使った書き方）：これもORMに近い
supabase.from('tweets').select('*').eq('user_id', userId);
3つは、まったく同じことを別の言い方でやっているだけです。並べて見比べてみましょう。
| やりたいこと | SQL | Prisma | Supabaseクライアント |
|---|---|---|---|
| どの表から？ | from tweets |
prisma.tweet |
.from('tweets') |
| 何を取る？ | select * |
findMany |
.select('*') |
| しぼり込み | where user_id = $1 |
where: { userId } |
.eq('user_id', userId) |
ORMやSupabaseクライアントで書いても、最終的には裏でSQLに翻訳されてデータベースに届きます。「SQLが消えた」のではなく、「見えなくなった」だけだと覚えておくと正確です。
⚖️ 利点と注意
便利な道具ですが、良い面とこわい面の両方があります。
🟢 利点（やさしくなるところ）
- 読み書きしやすい。 メソッドをつなげる形なので、SQLの文法を細かく覚えなくても書けます。
- 型が付いてミスに気づける。 TypeScript と組み合わせると、
tweetsに無い列名を打った瞬間にエディタが赤線で教えてくれる、ということが起きます。 - DBの細かな違いを吸収してくれる。 PostgreSQL でも MySQL でも、ほぼ同じ書き方が通じることが多いです。
🔧 注意（わかってから使いたいところ）
- 「魔法」を理解せずに使うと、裏で何が起きているか見えない。 たとえば一見シンプルな1行が、裏ではとても重いSQLを発行していることがあります。
- N+1問題に気づけない。 一覧を出すときに「ツイート一覧を取る命令（1回）」のあと、各ツイートの作者を「1件ずつ別々に取る命令（N回）」を裏でこっそり打ってしまう、という遅さの定番が N+1問題です（第8章）。ORMだとSQLが見えないぶん、起きていても気づきにくいのです。
- 最終的には、SQLが読めると強い。 ORMが翻訳した結果（実際のSQL）を読めれば、「なぜ遅いのか」を自分で突き止められます。ORMはSQLの代わりではなく、SQLの上に乗った便利な層だと考えるのが安全です。
🧱 マイグレーションという道具も一言 ORMには、たいていマイグレーション（テーブルの定義＝設計図の変更を、順番に記録して管理する仕組み）が付いています。「
tweetsに列を1つ足す」といった変更を、手作業ではなく履歴として安全に積み上げていくための道具です。名前だけ知っておけば十分です。
📝 ことばメモ
- ORM（オブジェクト・リレーショナル・マッパー）：SQLを書く代わりに、プログラムのオブジェクト/メソッドでDBを操作する道具。本編の Supabase クライアントもこれに近い。
- Prisma / Drizzle / SQLAlchemy / ActiveRecord：代表的なORMの名前。前2つは JavaScript・TypeScript、3つ目は Python、4つ目は Ruby on Rails。
- マイグレーション：テーブルの定義（設計図）の変更を、順番に記録して管理する仕組み。
- N+1問題：一覧を出すとき、関連データを1件ずつ別々に取りに行って遅くなる定番のワナ（第8章）。ORMだと見えにくい。
🔧 関連：SQLそのものをもっと知りたいなら付録C、データの「作る・読む・更新・消す（CRUD）」の流れは第5章で扱っています。