ORMの仕組み

ORMはObject-Relational Mapping、つまり「オブジェクトとリレーショナルデータベースの対応づけ」だよ。プログラムの中で使うクラスやオブジェクトを、データベースのテーブルや行に自動的に変換してくれる仕組みなんだ。例えばUserクラスのインスタンスを保存すると、usersテーブルにINSERT文が自動生成されて実行されるイメージだね。

実はプログラミング言語のオブジェクトとデータベースのテーブルって、構造が根本的に違うんだ。これを「インピーダンスミスマッチ」って呼ぶよ。オブジェクトには継承やメソッドがあるけどテーブルにはない。オブジェクトは他のオブジェクトへの参照を持つけど、テーブルは外部キーで関連づける。この溝を埋めてくれるのがORMなんだ。

基本ルールは3つ。クラスがテーブルに対応、プロパティ（フィールド）がカラムに対応、インスタンス（オブジェクト1個）が行に対応するよ。例えばUserクラスのnameプロパティはusersテーブルのnameカラムになる。関連づけも定義できて、「UserはPostを複数持つ」みたいな1対多の関係をhasMany()やOneToMany()で宣言すると、JOINやサブクエリを自動生成してくれるんだ。

関連データをいつ取りに行くかの戦略だよ。遅延ローディング（Lazy Loading）は「必要になったとき初めてSQLを発行する」方式。例えばuser.postsにアクセスした瞬間にSELECT文が走る。即時ローディング（Eager Loading）は「最初からJOINで一緒に取ってくる」方式だね。遅延ローディングは便利だけど、実は大きな落とし穴があるんだ。

N+1問題だよ。例えば100人のユーザー一覧を表示するとき、まず1回のSQLで100人分を取得する。次に各ユーザーの投稿を表示しようとすると、遅延ローディングでユーザーごとに1回ずつSQLが走って、合計101回のSQLが実行される。これがN+1問題。100人なら101回、1000人なら1001回。対策は即時ローディングで最初から2回のSQLで全部取るか、バッチローディングでまとめて取得することだね。

JavaならHibernate、PythonならSQLAlchemy、Node.jsならPrismaやTypeORMが有名だよ。特にPrismaは最近人気で、スキーマ定義ファイルからTypeScriptの型を自動生成してくれるから、SQLのタイプミスがコンパイル時に見つかる。各ORMで設計思想が違っていて、大きく分けるとActive RecordパターンとData Mapperパターンの2種類があるんだ。

Active Recordは、オブジェクト自身がデータベース操作のメソッドを持つパターン。user.save()やUser.find(1)みたいに書ける。Ruby on RailsのActiveRecordやLaravelのEloquentがこれだね。一方Data Mapperは、オブジェクトとデータベース操作を分離するパターン。オブジェクトは純粋なデータだけを持ち、別のRepositoryクラスがDB操作を担当する。HibernateやTypeORMがこっちだよ。

小〜中規模ならActive Recordの方がシンプルで書きやすい。でも大規模になるとビジネスロジックとDB操作が混ざって辛くなるんだ。Data Mapperはテストしやすいし、ドメインロジックをDBに依存させずに書ける。ただ設定やコード量が増える。これは「便利さ vs 柔軟性」のトレードオフだね。

あるよ。ORMが生成するSQLは汎用的だから、複雑な集計やバルクインサートでは手書きSQLの方が圧倒的に速いことがある。ベテランエンジニアの間では「ORMは8割のクエリを楽にして、2割のクエリを地獄にする」って言われることもあるんだ。だから多くのORMは生SQLを書ける逃げ道を用意しているし、Prismaのようにクエリビルダー寄りのアプローチで「型安全だけどSQLに近い」書き方を提供するものも増えてるよ。使い分けが大事だね。