.net - DataTableSelectとLINQSelect

Question

インメモリDataTableを処理するときにDataTable.Selectを使用する場合とLINQSelectを使用する場合についてのアドバイスはありますか？

LINQ構文はより簡単で強力だと思いますが、DataTableの選択を望ましいものにするパフォーマンスやその他の問題があるかどうかはわかりません。

（データベースから事前入力されたDataTableを提供するサードパーティのAPIを使用しています。さらにメモリ内でフィルタリングする必要があります。）

Answer 1

個人的な経験に基づいて、Datatable.Selectを避けようとしています。私はそれが遅く、いくつかの奇妙なバグがあることに気づきました。

私が遭遇した（Microsoftによって確認および文書化された）バグの1つは、ステートメントに括弧が含まれている場合、DataTable.SelectがAND条件を常に正しく評価するとは限らないことでした。

たとえば、（Col1> 1）AND（Col <10）は正解を返さない可能性がありますが、Col1> 1 ANDCol<10は正しく機能します。

このバグは、すべてのコンピューターに表示されるわけではありません。私の場合、使用していたチェックは、開発プラットフォームと1台を除くすべてのクライアントコンピューターで正常に実行されました。このバグを発見した後、選択にLINQを使用するようになり、操作の速度が大幅に向上したことに気付きました。

補足：長い説明をしなくても、私の会社はデータベースを使用してデータを保存していません。 DataTablesを使用したすべての操作には、フラットファイルからロードされたメモリテーブルが含まれます。したがって、私はLINQ 2 SQLについて話しているのではなく、LINQtoDatasetについて話しているのです。

Answer 2

LINQについても言及せずに、DataTableを使用することはありません。絶対に必要な場合を除いて、どこでも選択します。ほとんどの場合、データベースで実行する必要があることをクライアントで実行することを意味します。

更新：ここでの私の答えはおそらく少し誇張されています。クライアントからデータベースへのラウンドトリップを最小限に抑える（うまくいけば）小さなインメモリデータベースとしてDataTableを使用する正当な理由がある場合があります。

Answer 3

うーん、LINQ to SQLのデータセットを比較していますか？もしそうなら、私はデータセットを捨ててL2Sを使うと言うでしょう。 DataTable.Selectデータテーブルにデータがすでに入力されていることを前提としています。これは、クライアントでフィルタリングするためだけに、必要以上のデータをロードするという悪い設計につながる可能性があります。SQL Serverにクエリを実行させ、SQLServerが提供する結果セットで作業します。L2Sは、コレクションを反復処理する場合にのみデータベースから読み取るため、データベースにアクセスする前にクエリを作成する方がはるかに簡単です。

LINQ to SQLは、動的に生成されたSQLを取得するのが難しいため（最初にSQLを提供しているデータセットでは）、デバッグのオーバーヘッドが発生しますが、他のほとんどすべての状況では、はるかに洗練されています。遅延ロード機能は特に便利です。

データベースを使用していない場合でも、データセットよりもLINQ（具体的にはこのシナリオではオブジェクトよりもLINQとして知られています）を使用したいと思います。構文ははるかに簡単で、マジックストリング（つまりSQLステートメント）がないため、テストが簡単で、タイプミスなどのコンパイル時の警告が表示されます。