Linq над хранимыми процедурами

Question

Какие плюсы и минусы использования linq над хранимыми процедурами?

Answer 1

Так как никто не добавил CON - я предложу один здесь ...

Хранимые Procs предлагают вам возможность запретить выбор / вставку / удаление / обновление ваших базовых таблиц и представлений, чтобы вы могли иметь потенциально лучшую безопасность при использовании хранимых процедур, как вы могли бы использовать Linq to SQL. Предоставляя разрешения exec только вашим процессорам, вы получаете меньшую площадь поверхности для управления в целях безопасности.

Конечно, вы все равно можете использовать Linq для SQL и хранимые процедуры вместе - возможно, это был бы лучший вариант.

Answer 2

LINQ - прекрасное дополнение к .Net Framework, но у него есть свои ограничения. На данный момент LINQ еще не поддерживает весь синтаксис SQL (хотя я уверен, что они работают над этим). Кроме того, в LINQ нет простого способа обработки нескольких таблиц и предоставления нам только тех данных, которые нам нужны. С LINQ вам нужно будет извлечь все данные, затем сохранить то, что вы хотите, и выбросить все остальное, передав таким образом больше данных, чем фактически необходимо, что является проблемой производительности.

Если все, что вы делаете, это простые операторы INSERT, UPDATE и DELETE, то LINQ - это путь (на мой взгляд), и вся оптимизация сделана для вас, для более сложной работы я бы сказал придерживаться хранимых процедур. .

Answer 3

С моей точки зрения, основная ценность хранимых процедур была устранена с помощью LINQToSQL. Долгое время ключевым значением использования хранимых процедур было инкапсулирование SQL в форму, в которой вы естественным образом использовали бы параметризованные запросы. Это обеспечило разработчику уровень безопасности в отношении внедрения SQL. Поскольку запросы LINQToSQL по умолчанию параметризованы, я считаю, что мое использование хранимых процедур значительно сократилось.

Это не значит, что для них еще нет места, но теперь я чувствую, что вы должны использовать их только тогда, когда они обеспечивают значительную ценность по сравнению с параметризованным запросом LINQ с точки зрения меньшей сложности или повышенной производительности, возможно, из-за способность сервера оптимизировать процедуру. Я считаю, что устранение чрезмерной зависимости от хранимых процедур приводит к более удобной для сопровождения базе кода, поскольку большая часть кода находится в вашей IDE, а не разделяется между вашей базой данных и вашей IDE.

Обратите внимание, что вы все еще можете использовать хранимые процедуры с LINQToSQL. Я просто не вижу в этом особой ценности. На самом деле, я не могу вспомнить ни одной хранимой процедуры, которую я написал с момента перехода на LINQToSQL, хотя я написал несколько табличных функций для выполнения конкретных поисков. Они добавляются в мой DataContext и отображаются как методы, которые я могу вызвать, чтобы получить соответствующие объекты из БД с помощью функции.

Answer 4

Есть несколько вещей, которые я хотел бы добавить к обсуждению:

• Линк менее вероятно попадет в кешированный план выполнения в SQL Server, чем хранимая процедура. Хотя компиляция базовых операторов выбора является легкой, в более сложных запросах компиляция может быть довольно дорогой. ( В силу многих факторов сделать это утверждение истинным / ложным для вашей ситуации , но это, вероятно, для другого поста).

• Если у вас перекошенная перекомпиляция данных, на самом деле может быть полезно предотвращение нечетных решений об использовании индекса SQL. Подумайте select * FROM Person where LastName = @Letter Первый проход, где @Letter='Z' (скажем, 0,25% от общего числа людей) против @Letter='S' (6,00% от общего числа людей) может привести к совершенно разным планам выполнения.

• Linq эффективно вводит в наш код ad hoc sql. Конечно, через слой абстракции и на новом языке, но я больше не звоню exec GetOrders @DateStart=@now @DayRange=7, вместо этого я записываю имя таблицы, предложение where и порядок по.

• Отслеживание неэффективных операторов SQL обратно в код, который сгенерировал операторы, является более сложным, чем с SP. В среде большого объема SQL-профилировщик часто запускается на регулярной основе для поиска неэффективных запросов (высокая загрузка ЦП, чтение или длительность). Поскольку Linq абстрагирует текст, который он генерирует, становится трудно отследить sql до определенного места в коде, особенно в больших приложениях.

• В качестве примечания: при необходимости Linq может вызывать определенную хранимую процедуру, а не генерировать собственный SQL. Смотрите эту статью Скотта Гу .

Answer 5

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

Одной из основных причин использования any ORM является увеличение скорости разработки. Всякий раз, когда у вас есть компонент, который будет создавать для вас запросы, это на одну вещь меньше, чем вы сами.

Answer 6

Я не понимаю, почему в каждой дискуссии на эту тему предполагается, что писать SQL сложно, а писать запросы linq - нет. Несмотря на то, что простой linq действительно прост, как только вы захотите написать запрос, который обращается ко многим таблицам со сложными внешними объединениями, он просто становится невероятно грязным. Мало того, но я понятия не имею, как базовый движок будет обрабатывать мой запрос, и если он не работает, его очень сложно отладить.

Мне в 100 раз легче быстро написать сложный кусок SQL (если я вырос с этим, но, конечно, я не единственный), чем делать то же самое в linq.

Если мне нужно настроить его в сохраненном процессе, я просто настрою его и выпущу новый сохраненный процесс. Мне не нужно делать полную сборку приложения, потому что код встроен в него.

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

Тем не менее, каждая презентация на linq говорит, что вам больше не нужно изучать SQL. И все же SQL - такой хорошо понятный, зрелый язык. Черт, я бы предпочел, чтобы я мог поместить SQL непосредственно в мой код C # вместо того, чтобы изучать новый синтаксис.

Даже теория кросс-доступа к базе данных «если я напишу ее в linq, я могу использовать любую базу данных, которую захочу», меня не интересует, особенно если я пишу, скажем, SQL Azure, где я точно знаю, какая база данных это будет.

Итак, это моя напыщенная речь (которая уже давно накапливается!) На эту тему. Я бы хранил проки. Если вы хотите, чтобы тип был безопасным, загрузите результаты в четко определенные бизнес-объекты или, если хотите, linq to sql entity.

Answer 7

Я говорил об этом с кем-то здесь на днях, так как в настоящее время мы используем хранимые процедуры для всего доступа к базе данных. Мы обсуждали LINQ в целом, а также реализацию LINQ to SQL, IQueryable и т. Д. Она быстро поняла, что использование LINQ с sprocs будет в лучшем случае избыточным, а в худшем - сложным.

Преимущества LINQ to SQL в том, что код живет в одном месте, и то, что происходит в БД, очень ясно. Кроме того, время разработки может быть меньше, в основном в зависимости от процесса, так как требуется сделать еще один рабочий продукт.

Преимущества Sprocs, на мой взгляд, также двояки. Хранимые процедуры обеспечивают намного лучший контроль доступа для администратора баз данных, поскольку они могут проверять sproc перед развертыванием и позволяют приложению использовать доступ только для выполнения этого sproc, а не для чтения / записи всех необходимых таблиц. Это позволяет гораздо лучше анализировать проблемы с базой данных и проблемы с производительностью. Другое преимущество, которое я вижу, состоит в том, что, хотя LINQ to SQL будет генерировать правильный запрос, в случае сложных запросов бывают случаи, когда вы сталкиваетесь с случаем, который приводит к плохой оптимизации на стороне БД. В этих случаях вы либо переписываете запрос, либо предоставляете подсказки оптимизатору, и то и другое сложно / невозможно / разорвать метафору с помощью LINQ.

Может быть, это DBA во мне (не DBA, но был), но я очень нервничаю, работая над большой БД с высокой транзакционной нагрузкой и не зная точно каждого возможного оператора, который будет выполнен системой. Так что я сам придерживаюсь звезд.

Answer 8

Как насчет модульности?

Одна вещь, которую я нахожу с LINQ-to-SQL, заключается в том, что в случае ошибки нам может понадобиться перекомпилировать и заново развернуть все приложение (или только затронутые DLL), но с помощью хранимых процедур мне просто нужно исправить одна хранимая процедура, и моя работа выполнена.

Мне кажется, что LINQ чувствует себя более быстрым, а хранимая процедура - более формальной.

Опять же, мне нравятся LINQ и функции, которые идут с этим ... но не совсем продаются на LINQ-TO-SQL.

Answer 9

Я широко использую LINQ-to-SQL в своих проектах и ​​обнаружил, что он работает так же хорошо, как и SP почти во всех случаях.

В некоторых случаях вы теряете производительность / способность при использовании LINQ-to-SQL, без сомнения:

• Поскольку запросы заключаются в код с помощью LINQ, вы не можете использовать встроенный в SQL инструмент оптимизации запросов / оптимизации индекса (как легко). Такие вещи, как отслеживание планов выполнения, также делают дополнительный шаг (получение сгенерированного sql). Довольно тривиально, я думаю.

• Если у вас ситуация с действительно низкой пропускной способностью, отправка дополнительного текста параметризованного запроса по проводам израсходует большую пропускную способность, чем просто отправка вызова хранимой процедуры. Так что, если вы пишете приложение для Windows, которое обменивается данными через модемное соединение, это может быть более серьезной проблемой, чем веб-приложение (где серверы расположены рядом друг с другом), или если вы находитесь в ситуации очень интенсивного использования .