ORM を使用することの価値は、クエリ結果をオブジェクト フィールドに割り当てるという面倒な作業を自動化し、オブジェクト フィールドへの変更を追跡してデータベースに保存できるようにすることで、開発のスピードアップに役立つことです。そのため、オブジェクト リレーショナル マッピングという用語が使われています。
ORM は、デプロイ先の 1 つのデータベースしか使用しないため、データベースの移植性に関してほとんど価値がありません。
ORM のランタイム パフォーマンスの側面は、単純な SQL を自分で書くよりも優れているわけではなく、通常ははるかに劣っています。あなたが言及したように、クエリ生成の一般的な方法はしばしば単純な間違いを犯し、冗長なクエリをもたらします。繰り返しになりますが、利点は実行時の効率ではなく、開発時間にあります。
ORM を使用する場合と使用しない場合では、スケーラビリティに大きな違いはないようです。スケーラビリティのためのより価値のある他の手法には、次のものがあります。
- RDBMS でのインデックスの管理。O(n) から O(log 2 n)にできるだけ多くのアルゴリズムを改善します。
- インテリジェント キャッシング アーキテクチャ。
- データベースのパーティショニング/シャーディングによる水平スケーリング。
- データベースの負荷分散と複製。可能な場合はスレーブ データベースから読み取り、単一のマスター データベースに書き込みます。スレーブとマスターに異なるインデックスを付けます。
- Sphinx Search などの補完的なテクノロジで RDBMS を補完します。
- ハードウェアを問題に投入することによる垂直方向のスケーリング。Jeff Atwood は StackOverflow ポッドキャストでこれについてコメントしています。
一部の人々は、クラウド コンピューティングまたは分散非リレーショナル データベースを使用して、データ管理を分散アーキテクチャに移行することを提唱しています。これは、非常に多くのユーザーを獲得するまで、おそらく必要ありません。ある程度の大きさになると、すべてのルールが変わり、RDBMS を使用できなくなる可能性があります。しかし、あなたが Yahoo、Facebook、LinkedIn のデータ アーキテクトでない限り、心配する必要はありません。クラウド コンピューティングは誇張されすぎています。
データベースは常に Web アプリのボトルネックであるという共通認識がありますが、フロントエンドの効率を改善することが少なくとも同じくらい重要である場合もあります。参照。スティーブ・サウダーズの本。
Julia Lerman in Programming Entity Framework (2009), p.503 は、DataReader を直接使用する場合と Microsoft の LINQ to Entities を使用する場合で、クエリの実行コストが 220% 増加することを示しています。
また、Jeff Atwood のAll Abstractions are Failed Abstractionsに関する投稿も参照してください。LINQ を使用すると、単純な方法であってもプレーン SQL を使用する場合の少なくとも 2 倍のコストがかかることが示されています。