ORM（オブジェクト関係マッピング）

ORM とは

プログラムの世界では「ユーザー」「注文」を オブジェクト として扱いますが、DB ではそれらは テーブルの行 です。この2つの世界を自動で対応づけ、SQL を直接書かなくてもメソッド呼び出しでデータを読み書きできるようにするのが ORM（Object-Relational Mapping） です。

たとえば、生の SQL ならこう書く処理が、

SELECT * FROM users WHERE id = 42;

ORM ではこのようにオブジェクト操作で書けます（記法はライブラリにより異なります）。

user = User.find(42)      // 1行を User オブジェクトとして取得
user.name = "Taro"
user.save()               // UPDATE 文を自動生成して実行

何が嬉しいのか（利点）

• 定型処理を肩代わり: 1件取得・保存・削除といった CRUD の決まりきった SQL を、ライブラリが生成してくれる。
• オブジェクト指向のまま書ける: テーブルの行ではなく、慣れたオブジェクトとして扱える。関連（ユーザーの注文一覧など）もプロパティでたどれる。
• DB 差異の吸収: 多くの ORM は方言の違いをある程度吸収し、別の DB へ移しやすくする。
• 安全性: 値を自動でバインドするため、素朴な文字列連結による SQL インジェクションを避けやすい。

観点	生 SQL	ORM
定型 CRUD	毎回手書き	メソッドで自動生成
学習コスト	SQL の知識が必要	ライブラリの作法を学ぶ
複雑な集計・チューニング	思い通りに書ける	苦手・回りくどくなりがち
生成 SQL の見通し	明確	隠れて見えにくい

代表的な落とし穴：N+1 問題

ORM で最も有名な性能問題が N+1 問題 です。一覧（N件）を取得したあと、各要素の関連データを1件ずつ取りに行き、1 + N 回のクエリが飛んでしまう現象です。

posts = Post.all()                 // 1回：投稿を10件取得
for post in posts:
    print(post.author.name)        // 各投稿ごとに author を1回ずつ取得 → 10回
// 合計 1 + 10 = 11 回のクエリ

投稿が増えるほどクエリ数が線形に膨れ、DB への往復が重なって急激に遅くなります。

その他の注意点

• 生成 SQL が見えにくい: 何が実行されているか把握しづらい。開発時はログで実際のクエリを確認する習慣が有効です。
• 複雑なクエリは不得手: 高度な集計やウィンドウ関数などは、ORM 経由だと回りくどくなりがち。素直に生 SQL を書ける「逃げ道」を併用するのが現実的です。
• オブジェクト指向と表構造のミスマッチ: 継承や多対多の関係など、オブジェクト側の構造をテーブルへどう落とすかで設計判断が要ります（いわゆるインピーダンス・ミスマッチ）。

ORM は生産性を大きく高める道具ですが、SQL を「書かなくてよい」だけで「知らなくてよい」わけではありません。裏でどんなクエリが出ているかを意識できる人ほど、ORM をうまく使いこなせます。