LinqToSQLデザインクエリ/心配

Question

誰かが私を正しい方向に向けることができるのだろうかと思います。私は最近、LinqToSQLで遊んできました。強く型付けされたデータオブジェクトなどを好きになりました。

データベースパフォーマンスなどへの影響を理解するのは難しいです。たとえば、単純なユーザープロファイルページを開発していました。このページには、ユーザーに関する基本情報、最近の活動に関する情報、未読の通知のリストが表示されます。

このページのストアドプロシージャを開発していた場合、必要なすべての情報をカバーする複数のデータテーブルを返す単一のSPを作成することができました。

LinqToSQLを使用すると、多くのコールが発生する可能性があります.1つはユーザ情報、1つはアクティビティ、1つは通知です。通知の詳細情報が必要な場合は、複数のdbコールを呼び出します。

このデザインパターンを使用した結果、起こっているdbコールの数が心配すべきでしょうか？つまり、複数のDBハンドシェイクなどが私のdbなどを劣化させるのですか？

これに感謝します。

おかげ デビッド

Answer 1

あなたはそのルートを行く必要がある場合はSQLにLINQは、ストアドプロシージャから複数の結果を消費することができます。残念なことに、デザイナーはそれらを正しくマップする際に問題があるため、おそらく手動でマッピングを作成する必要があります。 http://www.thinqlinq.com/Default/Using-LINQ-to-SQL-to-return-Multiple-Results.aspxを参照してください。

すべての親レコードに必要となることがわかっている場合は、子レコードを熱心に読み込むようにLINQ to SQLを構成できます。 DataLoadOptionsおよび.LoadWithを使用して構成します。

LINQクエリのSelect句に複数の子コレクションを含むオブジェクトグラフを投影して、DBヒット数を減らすこともできます。

最終的には、状況に応じて最適なパフォーマンスを判断するためにいくつかのオプションを確認する必要があります。それはすべてのシナリオに適合する1つのサイズではありません。

Answer 2

は、パフォーマンスの観点から、最悪のことですか？はい、そうでしょう。複数のラウンドトリップは、通常、シングルよりも悪いです。

本当の質問はありますか？ストアドプロシージャの追加された複雑性を保証するのに十分な訪問数をアプリケーションが受け取るか？あるいは、生のパフォーマンスよりも将来の変更の単純さを大切にしていますか？

いずれの場合でも、パフォーマンスが必要な場合は、ストアドプロシージャを作成してコンテキストにマッピングできます。これはあなたに1つのコールを与えるが、そのオプションについて少し説明する記事をここ オブジェクトであるとしてデータを返します。 linq-to-sql-returning-multiple-result-sets