100,000〜200,000レコードを操作する必要があります。
これを行うために（SQLに対して）LINQを使用することを考えています。
私は経験から、データビューのフィルタリングが非常に遅いことを知っています。
では、LINQはどれくらい速いのでしょうか？
あなたの経験と、それを使用する価値があるかどうかを教えてください。それとも、SQLストアドプロシージャを使用したほうがよいでしょうか（処理量が多く、柔軟性が低い）。
データのグループを見つけて処理する必要がある数千のレコード内で、各グループには約50のレコードがあります。
5447 次
7 に答える
19
LINQ to SQL はクエリ式を T-SQL に変換するため、クエリのパフォーマンスは、ADO.NET 経由でその SQL クエリを送信した場合とまったく同じになります。クエリの式ツリーを同等の T-SQL に変換するには、多少のオーバーヘッドがあると思いますが、実際のクエリ時間と比較すると、これは小さいということが私の経験です。
もちろん、T-SQL が生成されたものを正確に見つけることができるため、適切なサポート インデックスがあることを確認してください。
DataViews との主な違いは、LINQ to SQL ではすべてのデータがメモリに取り込まれ、そこでフィルター処理されるわけではないことです。むしろ、データベースに得意なことをさせ、一致するデータのみをメモリに取り込みます。
于 2008-09-22T16:25:27.613 に答える
12
それはあなたがしようとしていることに依存します。LINQ はデータベースからデータを取得するのに非常に高速でしたが、LINQ-to-SQL は要求を SQL に直接変換して実行します。ただし、状況によっては、ストアド プロシージャを使用した方がよい場合もあります。
たとえば、いくつかのテーブルとかなり強力なキーを含むクエリを実行する必要があるデータがあります。LINQ を使用すると、クエリをカスタマイズするのに LINQ の柔軟性が比較的低いため、これらのクエリには数分かかります。SQL を手動で微調整することによって (つまり、JOIN のデータ強度を最小限に抑えるために 'WHERE' 型の引数を JOIN に配置することによって)、パフォーマンスを大幅に改善することができました。
私のアドバイスは、できる限り LINQ を使用することですが、LINQ によって生成された SQL が単に遅すぎると判断した場合は、ストアド プロシージャ ルートに進むことを恐れないでください。また、必要なことを達成するために SQL を手動で簡単に調整できます。
于 2008-09-22T16:27:15.313 に答える
3
レコードを操作することで何を意味するかをより具体的にする必要があります。変更がレコードごとに 100% 個別ではなく、セットベースで行うことができる場合は、データベース側 (ストアド プロシージャ) で T-SQL の変更を行う方がよいでしょう。つまり、可能であれば、ネットワークやプロセスの境界を越えて大量のデータをプルすることは避けてください。
于 2008-09-22T16:27:35.657 に答える
1
LINQ で生成されたクエリが優れていることがわかりました。linq クエリに実装されているいくつかのベスト プラクティスがあります。たとえば、所有者からのプレフィックス テーブル名、回避 (*) などです。クエリが複雑な場合 (単純な結合以上のもの)、linq は常に適切なソリューションを見つけることがわかりましたが、私のソリューションは決して優れていませんでした (私の SQL プロファイラーによると)。
次に問題は、クエリを直接実行した方がよいか、クエリをストアド プロシージャにラップした方がよいかということです。実行計画が保存されるため、stored procの方が優れているはずです。しかし実際には、.net sql サーバー プロバイダーによる選択を行うときは、最初のパラメーターがクエリ テキストである特別なストアド プロシージャを呼び出します。とにかく実行計画はキャッシュされます。
あなたの店で複数の選択を行う場合は、保存された方が良いでしょう。
于 2008-09-22T16:36:08.727 に答える
0
LINQ to SQL は、最初にデータベースからオブジェクトを取得することによって機能することに注意してください。次に、プロパティの変更をオブジェクトに適用し、SubmitChanges を呼び出してそれらを永続化し、各行/オブジェクトが必要な更新ステートメントを発行します。
一括更新の場合、これは一度に行のバッチ全体に適用される単一の更新ステートメントを送信するほど効率的ではありません。
于 2008-09-22T18:58:21.660 に答える
0
ひもの長さはどれくらいですか? LInq to SQL の速度。使い方次第です。
このモデルでは、すべてのレコードを取得してからクライアントでフィルタリングするため、「データビューのフィルタリングは非常に遅い」です。しかし、Linq to SQL は、悪用しない限り、そのようには機能しません。
Linq クエリは、必要な最後の可能な時点でのみ評価されます。そのため、クエリが評価される前に、クエリに "where" 制限を追加できます。フィルターを含む式全体が、データベース上で実行されます。
Stackoverflow は Linq を使用しており、小さなデータベースではありません。
SQL または ORMS を介してデータベースにアクセスするストアド プロシージャを提唱する人もいます。これは他の質問で議論されています。たとえば、こことここ
私の意見では、場合によっては、プロの DBA に最適なストアド プロシージャを作成してもらいたいと思うでしょう。必要に応じて、Linq からこれにアクセスできます。しかし、データベースへのアクセス方法の 80% 以上はパフォーマンスが重要ではなく、ストアド プロシージャはこれらの方法では時間のかかるやり過ぎになる可能性があります。
更新の場合、「update ... where ...」を使用したストアド プロシージャまたは SQL でのセットベースのサーバー側操作は、複数のデータベース ラウンドトリップを使用してレコードの読み取り、レコードの書き込み、繰り返しを行うよりもはるかに高速です。 .
于 2008-09-22T16:29:17.977 に答える
-3
通常、その多くのレコードの操作は、データベースのできるだけ近くで行う必要があります。それが私の仕事であれば、ストアドプロシージャでそれを行うことになります。それは私個人です。Linq は、データ アクセスの上にあるもう 1 つの抽象化レイヤーであり、「通常の」ニーズ、つまり UI に送信される数百のエンティティに対してはうまく機能しますが、データ ウェアハウス タイプの操作の代わりと考えるべきではありません。
于 2008-09-22T16:25:18.237 に答える