4

私たちの開発は、LinqtoSqlおよびSql2005+XmlFieldsの面で大きな障害に遭遇しました。フィールドを含むXmlblobフィールドがあります...

<Profile name-first="Terry" name-last="Aney" [...more]/>

LINQ to SQLを活用するために、SQLでUDFを作成し、それをDataContextに追加して呼び出します（大まかにLINQ to SQLに基づいています（パート6-ストアドプロシージャを使用したデータの取得） ）。ただし、これらの関数を使用すると、SQLによるXMLインデックス作成は役に立たなくなります。14,000行の母集団に対してフィルタリングおよび順序付けされたクエリであり、デフォルトの30秒のCommandTimeoutでタイムアウトになります。しかし、コマンドテキスト（SQLプロファイラーによってスニッフィングされた）を取得し、UDFを直接XQueryと交換すると、クエリは1秒未満で完了します（明らかに必要なものです）。Xmlフィールドについて同様の質問（つまりこの質問）を見てきましたが、一般的な答えはUDFを使用することですが、広範囲に使用すると非効率的であることが証明されています。

コマンドテキストを取得し、適切なXQuery構文（正規表現を介して）でUDFを交換できる低レベルのポイントがあることを期待しています。理想的ではありませんが、それが実現可能な唯一の解決策です。コマンドテキストの翻訳、SQLとのCLR統合など、何でも可能です。

特定の状況では、これはすでに実行できます。たとえば、Tが匿名および/または複合/ネストされたタイプではないIQueryableが常にある場合は、GetCommandTextを呼び出してから、DataContext.Translate（）を呼び出すことができます。ただし、匿名/複雑なタイプやスカラークエリの場合、フックする場所が見つかりません。

どんな提案でも大歓迎です。

4

2 に答える 2

1

したがって、ここにいくつかの考えがあります。この関数は、返される行ごとに呼び出され、パフォーマンスが低下しますが、おそらくお気づきかもしれませんが、LinqtoSQLはXMLフィールドの大ファンではないようです。したがって、考えられる解決策は、関数を実際に最適化することです。これを行うための最良の方法は、SQLCLRを使用することです。このリンクを見て、彼がどのように実行したかを確認してください。

http://conficient.wordpress.com/2011/01/20/querying-xml-fields-in-linq-to-sql/

于 2011-02-18T07:52:21.197 に答える
0

参考までに、私の同僚は問題を「解決」しました。少し「悪」ですが、私たちのために仕事をしています。 http://chriscavanagh.wordpress.com/2011/03/12/manipulating-linq-to-sql-command-text/

基本的に、変更できるようになったので、明らかにUDFであるいくつかの「プレースホルダー」関数をL2SDataContextに作成しました。ただし、コマンドをインターセプトし、それらを適切なXQuery value / examples（）構文に交換して、可能な限りパフォーマンスが高いことを確認します。

于 2011-03-14T18:41:55.757 に答える