LINQ-to-SQL CompiledQuery.Compile () с обновлением, удалением, вставкой? - PullRequest
7 голосов
/ 10 декабря 2008

All

Итак, все мои запросы select в LINQ-to-SQL преобразованы в использование CompiledQueries для ускорения работы. Пока отлично работает для операторов select, но я не смог выяснить, как предварительно скомпилировать операторы вставки, обновления или удаления.

Конечно, когда вы вставляете, удаляете или обновляете в LINQ-to-SQL, вы должны использовать объектную модель. Но, очевидно, где-то по пути он генерирует запрос, который было бы неплохо предварительно скомпилировать и сохранить в статическом члене.

Возможно ли это? Какова производительность LINQ для обновлений, удалений и вставок, когда они предварительно не скомпилированы? Я мог видеть, что это намного быстрее, чем селекты, потому что то, что они делают внизу, намного проще и менее «динамично» ...

Ответы [ 3 ]

8 голосов
/ 10 декабря 2008

Есть большая разница. Запросы выбора Linq-To-SQL могут быть большими деревьями сложных выражений. Это то, что может занять время «компиляции». В этом случае объединение с некоторым T-SQL, который может быть запущен против SQL Server. Поэтому имеет смысл кэшировать результат операции, чтобы ее можно было использовать повторно.

Однако другие операции удаления, обновления и вставки являются простыми операциями, для которых не требуется преобразовывать дерево выражений в T-SQL (сама LINQ полностью связана с запросами). Очень жаль, что нас научили думать о коде SQL, который выполняет эти другие операции, как о «запросах», мы вообще не просим никакой информации.

Эти операции определяются только DataContext, а не LINQ, поэтому код для выполнения этих функций уже скомпилирован.

3 голосов
/ 10 декабря 2008

Я думаю, что только три вставки имели бы смысл иметь возможность компилировать и повторно использовать, потому что удаление тривиально просто (УДАЛИТЬ ИЗ таблицы, ключ WHERE ...), а UPDATE обновляет только те поля, которые были изменены, и поэтому изменяется операция обновления.

[) Amien

0 голосов
/ 10 декабря 2008

L2S использует "sp_executeSQL", поэтому после первого запуска он будет находиться в кэше плана выполнения хранимой процедуры. Последующие запуски (одного и того же запроса, а не тех же параметров) будут повторно использовать скомпилированный план из кэша. Таким образом, то, что вы запрашиваете, автоматически обрабатывается SQL Server «за кулисами».

...