私は ASP.net/SQL Server 開発環境で働いています。私の唯一の懸念が速度である場合、パラメーター化されたクエリを使用する必要がありますか、それとも nHibernate や LINQ などの ORM を使用する必要がありますか?
5 に答える
すべてが等しい場合、ORM はオーバーヘッドを追加するため、最初は不利になります。
一方、ORM はユーザーよりも効率的な SQL を生成する可能性があり、それらの多くには、自分で記述する必要のない組み込みのキャッシュ機能が付属しています (目的に合っている場合、そのキャッシュから得られる改善は、追加のオーバーヘッドで失うものよりも大きくなります)。
ほとんどの ORM はパラメーター化されたクエリをサポートしているため、その点で違いはありません。可能な限り ORM を使用して実装し、必要な場合にのみ SQL を手作りして最適化します。
ORM がどのように機能するかを理解すると、パフォーマンスの高いコードを作成するのに役立ちます。こうすることで、たとえば外部キーを介して別のテーブルにクエリを実行する場合など、ループ内でクエリを繰り返し呼び出すような明らかなトラップを回避できます。
キャッシュを使用しないクエリの速度だけが問題である場合は、ORM は必要ありません。ORM の主な機能は、ネイティブ クエリを実行する必要をなくして単純にコーディングすることだからです。ただし、最適な速度を得るために、ORM でネイティブ クエリを使用する必要がある場合があります。それでも、パラメータ化されたクエリを手動で使用するよりも抽象化に時間がかかる場合があります。
ただし、クエリがオブジェクトをキャッシュすることでメリットが得られる可能性がある場合は、ORM を使用すると速度が向上する可能性があります。
これに対する答えは、実際には「場合による」であり、確認のために自分の環境でテストする必要がありますが、一般的に、ORM ツールを使用すると抽象化のレイヤーが追加され、オーバーヘッドが発生する可能性があります。SQL を書くのが本当に苦手な場合は、ORM の方が良いかもしれませんが、その場合は、SQL スキルの向上に取り組むだけです。
編集:私は通常、パフォーマンスに基づいてORMとORMなしのどちらかを決定しないことを付け加えたいと思います。他の要因に基づいて選択を行い、そのコンテキスト内で設計を最適化します。
オーバーヘッドは、クエリ自体ではなく、マッピングの実行、変更の追跡などから発生します。マッピングは非常に高速ですが、操作で 100,000 レコードを操作している場合は、ストレート sql が優先されます。ただし、操作で 100,000 レコードを処理する場合は、ORM を使用しないでください。