LINQ-SQL по сравнению с хранимыми процедурами? [закрытый]

Сохраненный Procs по сравнению с Кодом (Предыдущее обсуждение)

Я предполагаю, что Вы значите Linq Для Sql

Для любой команды CRUD, легко представить производительность хранимой процедуры по сравнению с любой технологией. В этом случае любое различие между этими двумя будет незначительно. Попытайтесь представить для 5 (простые типы) объект поля более чем 100 000 запросов Select, чтобы узнать, существует ли реальная разница.

, С другой стороны, реальное недопустимое будет вопросом на том, чувствуете ли Вы себя комфортно, помещая Вашу бизнес-логику на Вашу базу данных или нет, который является аргументом против хранимых процедур.

Кроме того, существует проблема возможных 2,0 откатов. Доверяйте мне, это произошло со мной пару раз, таким образом, я уверен, что это произошло с другими.

я также соглашаюсь, что абстракция является лучшей. Наряду с фактом, исходная цель ORM состоит в том, чтобы составить соответствие RDBMS приятно к понятиям OO. Однако, если все хорошо работало, прежде чем LINQ при необходимости отклониться немного от понятий OO тогда завинчивают их. Понятия и действительность не всегда соответствуют хорошо вместе. Нет никакой комнаты для воинственных зилотов в IT.

LINQ не запрещает использование хранимых процедур. Я использовал смешанный режим с LINQ-SQL и LINQ-storedproc. Лично, я рад, что не должен писать сохраненный procs.... pwet-tu.

DBA А не имеет никакой свободы внести изменения в модель данных, не вынуждая Вас изменить Ваш скомпилированный код. С хранимыми процедурами можно скрыть эти виды изменений до степени, так как список параметров и набор (наборы) результатов, возвращенный из процедуры, представляют свой контракт, и внутренности могут переехаться, настолько долго поскольку тот контракт все еще выполняется.

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

LINQ определенно имеет свое место в специализированных базах данных и в предприятиях малого бизнеса.

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

Лучший код не является никаким кодом, и с хранимыми процедурами необходимо записать, по крайней мере, некоторый код в базе данных и код в приложении для вызова его, тогда как с LINQ к SQL или LINQ к Объектам, Вы не должны писать дополнительный код вне никакого другого запроса LINQ кроме инстанцирования объекта контекста.

LINQ является новым и имеет свое место. LINQ не изобретен для замены хранимой процедуры.

Здесь я сфокусируюсь на некоторых мифах о производительности & CONS, только для "LINQ к SQL", конечно, я мог бы быть полностью неправым;-)

(1) Люди говорят, что LINQ statment может "кэшироваться" в SQL-сервере, таким образом, это не теряет производительность. Частично верный. "LINQ к SQL" на самом деле является временем выполнения, переводящим синтаксис LINQ в TSQL statment. Таким образом с точки зрения производительности, трудный кодированный SQL-оператор ADO.NET не имеет никакого различия, чем LINQ.

(2), Учитывая пример, обслуживание клиентов UI имеет "функцию" передачи учетной записи. эта функция сама могла бы обновить 10 Таблиц базы данных и возвратить некоторые сообщения в одном выстреле. С LINQ необходимо создать ряд операторов и отправить их как один пакет к SQL-серверу. производительность этого перевела LINQ->, пакет TSQL может едва соответствовать хранимой процедуре. Причина? потому что можно настроить самую маленькую единицу оператора в Сохраненной процедуре при помощи встроенного инструмента профилировщика SQL и плана выполнения, Вы не можете сделать этого в LINQ.

точка при разговоре единственной Таблицы базы данных и маленького набора CRUD данных, LINQ с такой скоростью, как SP. Но для намного более сложной логики, хранимая процедура является большим количеством tweakable производительности.

(3) "LINQ к SQL" легко делает новичков для представления пожирателей ресурсов производительности. Любой старший парень TSQL может сказать Вам если не использовать КУРСОР (В основном, что Вы не должны использовать КУРСОР в TSQL в большинстве случаев). С LINQ и очаровательным "foreach" циклом с запросом, для новичка настолько легко записать такой код:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Вы видите, что этот легкий достойный код так привлекателен. Но под капотом, время выполнения.NET просто переводит это в пакет обновления. Если существует только 500 строк, это - 500 строк пакет TSQL; Если существует миллион строк, это имеет успех. Конечно, опытный пользователь не будет использовать этот способ сделать, это задание, но точка, настолько легко упасть таким образом.

Я думаю, что про аргумент LINQ, кажется, прибывает от людей, у которых нет истории с разработкой базы данных (в целом).

Особенно при использовании продукта как DB VS Pro или Комплект Команды, многие аргументы, приведенные здесь, не применяются, например:

Тяжелее, чтобы поддержать и Протестировать: VS обеспечивает проверку полного синтаксиса, проверку стиля, справочную и ограничительную проверку и т.д. Это также обеспечивает полные возможности поблочного тестирования и инструменты рефакторинга.

LINQ делает истинное поблочное тестирование невозможным как (в моем уме), это проваливает Тест на кислотность.

Отладка легче в LINQ: Почему? VS позволяет полный неродной в от управляемого кода и регулярной отладки SPS

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

не должны изучать TSQL с LINQ: Нет Вы не делаете, но необходимо ли изучить LINQ - где преимущество?

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

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

, Прежде чем Вы все будете расстроены, я думаю, что LINQ имеет свое место и имеет главное будущее. Но для сложных, информационно емких приложений я не думаю, что это готово занять место хранимых процедур. Это было представлением, которое я повторил MVP в TechEd в этом году (они останутся неназванными).

РЕДАКТИРОВАНИЕ: LINQ стороне Хранимой процедуры SQL вещей - что-то, что я все еще должен считать больше на - в зависимости от того, что я нахожу, что могу изменить мой выше резкой критики;)

LINQ чрезмерно увеличит размер кэша процедур

, Если приложение будет использовать LINQ для SQL, и запросы включают использование строк, которые могут быть очень переменными в длине, кэш процедур SQL Server станет чрезмерно увеличенным в размерах с одной версией запроса для каждой возможной длины строки. Например, считайте следующие очень простые запросы созданными против Человека. Таблица AddressTypes в базе данных AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

, Если оба из этих запросов выполняются, мы будем видеть две записи в кэше процедур SQL Server: Один связанный с NVARCHAR (7), и другой с NVARCHAR (11). Теперь вообразите, были ли сотни или тысячи различных входных строк, все с различными длинами. Кэш процедур стал бы излишне заполненным всеми видами различных планов относительно того же самого запроса.

Больше здесь: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx? FeedbackID=363290

Для извлечения основных данных я шел бы для Linq без колебания.

Начиная с перемещения в Linq я нашел следующие преимущества:

1. Отладка моего DAL никогда не была легче.
2. безопасность Времени компиляции, когда Ваша схема изменяется, является бесценной.
3. Развертывание легче, потому что все компилируется в DLL. Более руководящие сценарии развертывания.
4. , поскольку Linq может поддерживать запросы чего-либо, что реализует интерфейс IQueryable, Вы будете в состоянии использовать тот же синтаксис для запросов XML, Объектов и любого другого источника данных, не имея необходимость изучать новый синтаксис

Linq к Sql.

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

Ваши linq операторы, с другой стороны, будут логически частью и протестированный с Вашим приложением. Sprocs всегда немного разделяются и более тверды поддержать и протестировать.

, Если бы я работал над новым приложением с нуля прямо сейчас, я просто использовал бы Linq, никакой sprocs.

Я обычно - сторонник помещения всего в хранимых процедурах по всем причинам, на которых DBAs были harping в течение многих лет. В случае Linq это верно, что не будет никакого различия в производительности с простыми запросами CRUD.

, Но имеют в виду несколько вещей при принятии этого решения: использование любого ORM связывает Вас плотно с Вашей моделью данных. DBA не имеет никакой свободы внести изменения в модель данных, не вынуждая Вас изменить Ваш скомпилированный код. С хранимыми процедурами можно скрыть эти виды изменений до степени, так как список параметров и набор (наборы) результатов, возвращенный из процедуры, представляют свой контракт, и внутренности могут переехаться, настолько долго поскольку тот контракт все еще выполняется.

И также, если Linq используется для более сложных запросов, настраивая базу данных, становится намного более трудной задачей. Когда хранимая процедура отстает, DBA может полностью сфокусироваться на коде в изоляции и имеет много опций, именно так тот контракт все еще удовлетворен, когда он сделан.

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

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

IMHO, RAD = LINQ, RUP = Stored Procs. Я много лет проработал в крупной компании из списка Fortune 500 на многих уровнях, включая менеджмент, и, честно говоря, я бы никогда не нанял разработчиков RUP для разработки RAD. Они настолько разобщены, что у них очень ограниченные знания о том, что делать на других уровнях процесса. В изолированной среде имеет смысл предоставить администраторам баз данных контроль над данными через очень конкретные точки входа, потому что другие, откровенно говоря, не знают лучших способов управления данными.

Но крупные предприятия перемещаются болезненно медленно развивается, и это очень дорого. Бывают случаи, когда вам нужно действовать быстрее, чтобы сэкономить время и деньги, и LINQ предоставляет это и многое другое в избытке.

Иногда мне кажется, что администраторы баз данных предвзято относятся к LINQ, потому что считают, что это угрожает их безопасности работы. Но такова природа зверя, дамы и господа.