Выбор LINQ для SQL против StoredProcs

Question

При разработке приложений я обычно обращаюсь к хранимым процедурам, содержащим логику CRUD, чтобы повысить производительность и удобство обслуживания. Но после экспериментов с LINQ to SQL мне стало интересно, поможет ли использование скомпилированных запросов LINQ-to-SQL для хранимых процедур улучшить производительность?

Answer 1

Исходя из моего опыта, я могу оценить производительность следующим образом:

1. Хранимые процедуры
2. Собственные запросы (с использованием DBCommand)
3. Linq для сущности (скомпилированный запрос,EF4)
4. Linq для SQL (скомпилировано)
5. Linq для сущности (не скомпилировано EF4)
6. Linq для SQL

7. ESQL

   2,3,4 может изменить свой порядок в зависимости от характера запросов, но в целом необработанный SQL-запрос выполняется быстрее.

Answer 2

LINQ to SQL не улучшит вашу производительность, потому что вы будете отправлять каждую операцию CRUD в виде строки по проводам.

Производительность будет сохраняться при использовании хранимых процедур, но ORM, как Linq to SQL, обычно ускоряет разработку.

Answer 3

Судя по вашим комментариям как к DevSlick, так и к a1ex07, у вас возникло фундаментальное недопонимание того, что такое LINQ.Чтобы запросы LINQ разрешали связывание, например

var activePeople = peopleList.Where(o => o.Active).OrderBy(o => o.Ordering).Select(o => o.Name);

, выполнение запроса LINQ должно быть отложено до его перечисления:

foreach(var person in activePeople)
{
   //If this is LINQ-to-SQL, the query to peopleList has waited until now to request anything from the database
}

Это означаетчто запрос .Where(o => o.Active).OrderBy(o => o.Ordering).Select(o => o.Name) на самом деле не интерпретируется вашим компьютером до этого момента.Если вы выполняете один и тот же запрос 100 раз, это означает, что компьютер должен интерпретировать этот запрос 100 раз.Для LINQ-to-SQL это означает перевод запроса в SQL 100 раз, прежде чем этот SQL отправляется в базу данных каждый раз, даже если SQL каждый раз точно такой же.

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

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

static readonly Func<AdventureWorksEntities, Decimal, IQueryable<SalesOrderHeader>> s_compiledQuery2 = 
    CompiledQuery.Compile<AdventureWorksEntities, Decimal, IQueryable<SalesOrderHeader>>(
        (ctx, total) => from order in ctx.SalesOrderHeaders
                        where order.TotalDue >= total
                        select order);

var orders = s_compiledQuery2.Invoke(context, totalDue);

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