Является ли Linq to SQL быстрым при использовании хранимых процедур?

Question

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

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

Спасибо

Answer 1

Основным преимуществом здесь является то, что в среде IDE вы можете написать всю сантехнику для вас, то есть отсортировать параметры и возвращаемые данные.

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

Если вы хотите добиться максимальной производительности, мой совет:посмотрите на dapper-dot-net , который мы написали (и выпустили как OSS) после нахождения этих пауз материализатора.Использование довольно просто.В частности, это аккуратно позволяет вам использовать dapper для выполнения тяжелой работы, но все же использовать сгенерированные IDE типы для данных.

Внутренне мы не используем хранимые процедуры;мы используем комбинацию:

• кода дерева выражений LINQ-to-SQL
• кода LINQ-to-SQL ExecuteQuery (и т. д.)
• dapper-dot-net

Предпочтение производительности является (по нашему опыту) последним.Первый удобно писать, и часто достаточно быстро.Средний вариант - fast , но когда dapper имеет почти идентичный API (и быстрее), его сейчас трудно любить; p

Answer 2

С точки зрения построения SQL-кода есть немало накладных расходов.Это особенно очевидно при выполнении объемных вставок.Использование хранимых процедур может здесь помочь, так как вся логика генератора распределяется, а параметры сопоставляются с вызовом SP, который очень легкий.Для моего собственного приложения, в частности с одной из моих таблиц с более чем 100 столбцами, улучшение было впечатляющим - как минимум в четыре или пять раз быстрее, чем генерирование SQL на лету.

Это довольно легко сделать,тоже, пока вы тот, кто генерирует ваши классы сущностей.Просто объявите ваши методы расширяемости для Insert и Update в ваших сгенерированных классах сущностей.У вас будет дескриптор сущности, и оттуда вы сможете установить соединение ADO.NET для вызова SP.

Учитывая все это, на вашем месте я бы не стал спускатьсямаршрут, пока вы не подтвердите, что это то, где ваше узкое место производительности.Для большинства целей сгенерированный SQL работает достаточно хорошо.

Answer 3

Я рекомендую использовать хранимые процедуры при доступе к базе данных через LINQ-To-SQL или EF для повышения производительности.

Использование простого LINQ, который генерировал бы SQL-запросы, может быть весьма неэффективным, если речь идет о любом умеренно сложном запросе.

Answer 4

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