Что является более эффективным с Joins и множественным выбором, работающим с LINQ?

Question

У меня есть несколько сложных запросов с LINQ, которые за кулисами делают около 7-9 соединений.Я нахожусь в процессе оптимизации запросов. Теперь меня немного смущает пара вещей:

1. Должна ли у меня просто хранимая процедура , выполняющая, возможно, динамическийsql вместо того, чтобы использовать его как запрос LINQ. Когда хранимая процедура должна делать что-то вместо запроса LINQ ?Я думаю, это зависит .. но каковы лучшие практики?Когда должна быть хранимая процедура?Иногда я вижу, что LINQ делает какие-то странные неэффективные вещи за кулисами?Это мое беспокойство ..

2. Есть место, где я делаю множественный выбор ... по сравнению с тем, когда я могу объединяться с таблицами, но если я вступаю в нихэто становится немного сложнее (скажем, 7-9 объединений при по сравнению с 3-5 выборами).Я думаю, что лично присоединиться будет эффективным, не так ли?поскольку только один запрос к базе данных?Принимая во внимание, что с несколькими выборами он должен сделать несколько запросов?Что ты об этом думаешь ?

Answer 1

Есть много факторов, которые способствуют здесь, и есть много неизвестных для меня, поэтому подтекст для моего ответа «это зависит».

1) С четко определенным Datacontext LINQ-to-SQL обычно генерирует эффективные запросы. Фильтры автоматически параметризуются, что позволяет ядру базы данных кэшировать планы выполнения. Поэтому я считаю, что единственное время хранимых процедур будет работать лучше, если бы потребовались подсказки запроса или какой-либо другой механизм, не поддерживаемый генератором запросов. Я считаю, что наилучшей практикой является использование LINQ и использование sprocs только тогда, когда может быть продемонстрирована значительная оптимизация.

2) Обычно ограничение поездок в БД является оптимальным. Но чтение количества объединений, необходимых в ваших отношениях, заставляет задуматься, будет ли вам хорошо, если вы добавите представление. Это отвлечет сложность, представления хорошо интегрируются с LINQ и защитит ваш код от будущих изменений схемы.

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

Также, чтобы узнать больше о LINQ vs SProcs, ознакомьтесь с обсуждением в этом вопросе: LINQ-to-SQL vs хранимые процедуры?