私たちのDBAは、LINQクエリがデータベースに何千ものロックを作成しているという情報を持って来ました。私たちのチームの開発者は、私たちの問題に対する可能な解決策として、このハンゼルマンの投稿を掘り起こしました：
http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx
スコットは、LINQでNOLOCKを設定するための3つの方法を提供します。1）TransactionScope（推奨）、2）SPROCS、3）context.ExecuteCommand
私たちは99％が読み取り、1％が書き込みを行うニュースサイトであるため、検索の速度に重点を置いています。NOLOCKは、すべてのLINQ-TO-SQLクエリに適した戦略ですか？
私が理解しようとしているのは、NOLOCKを使用することがなぜ良い考えであるかそうでないかということです。私たちと同じ目標を持つ多くの人々がいるに違いありません：多くの高速読み取り、更新はほとんどまたはまったくありません。NOLOCKが明白な答えである場合、なぜそれがデフォルトではないのですか？すべてのデータ呼び出しで設定するのではなく、コンテキストのデフォルトにできないのはなぜですか？
NOLOCKは、多くの高速読み取り、少数の更新サイトにとって本当に最良のオプションですか？
更新：SQL Server 2005以降では、スナップショットアイソレーションはNOLOCKよりも優れていますか？ 私はちょうどこれを見つけました http://msdn.microsoft.com/en-us/library/ms179599.aspx
READCOMMITTEDSNAPSHOTをカバーしています。これは書き込みブロックを防ぎますが、ダーティデータを返しませんか？これは、NOLOCKよりも90％の時間使用する必要がありますか？
更新2：私を悩ませているのはDRYです
私が最も気になっているのは、ロックなしまたはスナップショットパターンのいずれかを実装するために、すべてのLINQ-to-SQLクエリメソッド（更新で使用されているものを除く）でそれを変更する必要があることです。これはDRYの重大な違反のようなにおいがします。