LINQ は間違いなくデータベース プログラミングを簡素化しますが、欠点はありますか? インライン SQL では、データベースをインジェクションに対してオープンにする特定の方法でデータベースと通信する必要があります。インライン SQL も構文をチェックし、プランを作成してから実行する必要があり、これには貴重なサイクルが必要です。ストアド プロシージャは、優れたデータベース アプリケーション プログラミングの堅実な標準でもあります。私が知っている多くのプログラマーは、開発を簡素化するデータ層を使用していますが、LINQ ほどではありません。SP をあきらめて LINQ に移行する時が来ましたか?
6086 次
7 に答える
6
LINQ to SQL は、実際にはデータベースに重大なパフォーマンスの問題をもたらします。基本的に、使用しているパラメータの長さに基づいて複数の実行計画を作成します。しばらく前に私のブログLINQ to SQL may cause performance problemsに投稿しました。
では、LINQ には居場所がないということでしょうか。しそうにない。ストアド プロシージャと同様に、LINQ は間違いなく開発ツールキットに含まれています。最終的には、パフォーマンスがどうしても必要な場合はストアド プロシージャを使用し、それ以外の場合は ORM ツールを使用します。
インライン SQL に関する限り、プランが一度だけ構築され、再コンパイルされないようにインライン SQL を実行する方法があります。ほとんどの ORM は、パフォーマンス チューニングのこの側面も処理する必要があります。これらのメソッドを使用すると、パラメータ化されたクエリを使用する必要があるため、通常、SQL を実行する最も安全な方法です。
ほとんどのデータベース ソリューションと同様に、正しい答えは、解決しようとしている問題によって異なります。データベース/アプリケーションのパフォーマンスよりも開発速度を優先する場合は、LINQ または別の DAL/ORM ツールを使用するのが最善の方法です。開発の容易さよりもパフォーマンスを優先する場合は、ストアド プロシージャと純粋なデータセットを使用するのが最善の策です。LLBLGen は LLBLGen レイヤーへの LINQ も提供するため、LINQ を使用して LLBLGen のオブジェクトをクエリし、LLBLGen に実際にクエリの構築を処理させて、LINQ の欠点のいくつかを回避することができます。
于 2008-09-16T15:48:57.027 に答える
3
あなたの基本的な前提に欠陥があります..
インライン SQL では、データベースをインジェクションに対してオープンにする特定の方法でデータベースと通信する必要があります。
いいえ、そうではありません。ユーザーが入力した値を SQL ステートメントにハードコーディングすることもできますが、ストア プロシージャを使用することもできます。
クエリをパラメーター化すると、インジェクション攻撃を防ぐことができますが、インライン SQL はストアド プロシージャと同じくらい簡単にパラメーター化できます。
インライン SQL も構文チェックし、プランを作成してから実行する必要があります。
すべての Sql (SP およびインライン) は、構文をチェックし、最初の呼び出しで計画を立てる必要があります。その後、リクエストの正確なテキストと実行計画がキャッシュされます。まったく同じテキスト (パラメーターをカウントしない) を持つ別の要求を受信した場合、キャッシュされた実行計画が使用されます。
そのため、値をインライン SQL にハードコーディングすると、テキストが一致せず、クエリを再解析する必要があります。ただし、パラメーターを使用すると、クエリのテキストが一致し、キャッシュ ヒットが発生します。その場合、クエリがインライン SQL であるか SP であるかは関係ありません。
つまり、インライン SQL の唯一の問題は、低速で安全でないことを簡単に実行できることです。しかし、インライン SQL を高速かつ安全にすることは、SP を使用するよりも簡単です。
これにより、LINQ ステートメントに値をハードコーディングした場合でも、常にパラメーターを使用する LINQ にたどり着き、「高速で安全な」インライン SQL が簡単になります。
LINQ には、2 つの異なるマシンに分散するのではなく、すべてのコードを 1 つの場所に配置できるという SP よりも優れた点もあります。
于 2008-09-16T17:42:20.497 に答える
2
ベンチマークに興味がある場合は、Rico Mariani が質的および量的な違いをカバーする優れた 5 部構成の調査を行っています。
彼は MS マニアかもしれませんが、パフォーマンス マニアとして知られています。彼のベンチマークは綿密でよく考えられています。
于 2008-09-16T13:41:20.857 に答える
1
列名を変更することを考えてみてください。今度は (n)SP と (x)View を変更してください。
データベースでコストのかかるすべてのこと (検索、並べ替えなど) を実行すると、問題に気付くことはありません。
また、ページングなしで大きなグリッドを表示したい場合は、データセットを使用してください - その方が高速です。
StackOverflow も linq2sql を使用しています - 問題はありますか :) ?
ORM を使用します。これは、ほとんどのアプリケーションで使用される方法です。
PS: また、マイクロ ベンチマークについても同様です。たとえば、ORM で 10.000 行を選択してみましょう。それが ORM を使用する理由ではありません。10.000 行を選択する場合は、ADO を使用します。
于 2008-09-16T14:29:04.300 に答える
1
マクシミリアン・ベラーによるパフォーマンスです。彼によると、LINQ ははるかに遅いです。 彼の包括的な研究を読む
于 2008-09-16T13:33:26.073 に答える
0
LINQ to SQL の構造上、独自の適切な形式のクエリまたはストアド プロシージャとして生の SQL を使用するよりも高速になる方法はありません。LINQ によって得られるのは、速度ではなく、型の安全性と組織です。簡単に言えば、ORM が一般的にもたらすメリットのほとんどを享受できます。
LINQ to SQL は速度ではなく、より保守しやすいソフトウェア システムを構築することを目的としています。疎結合や階層化など、専任のソフトウェア エンジニアやアーキテクトが関心を持っているすべてのことについてです。
これは、LINQ を使用して本当に保守しにくいコードを作成できないと言っているわけではありません。あなたが自分の足を撃たないようにする人は誰もいませんが、適切に実行すれば、LINQ は非常に役立ちます。ただし、LINQ が特効薬だと言っているわけではありません。多くの企業の状況での使用を困難にする多くの問題があります。これが、MS が Entity Framework (ADO.NET 3.0) を提供する理由です。もちろん、最近の EF の不信任投票を考えると、それでも完璧ではありません。
LINQ to SQL または EF は生の SQL よりも優れていますか? 私は響き渡る地獄だと思います。よりうまく機能する可能性のある他のソリューションはありますか? 多分。
于 2008-09-16T15:23:19.910 に答える
0
それはあなたが何をしているかによります。LINQ は、実際のデータベースよりも実際のデータ/セット操作の効率が低くなります。ただし、ネットワーク経由でデータベースに接続する必要がないため、大幅に節約できます。
データベースが同じマシン上にある場合、または正式に「適切に接続されている」場合は、おそらくそれを使用する方がよいでしょう。
しかし、リモート データベースから大量の結果セットを取得する場合は、かなりの転送時間がかかる可能性があります。または、オーバーヘッドを正当化できない非常に短いクエリである場合は、LINQ の方が優れている可能性があります。
于 2008-09-16T13:41:02.997 に答える