LINQ-to-SQL и хранимые процедуры?

Я взглянул на сообщение "Beginner Guide to LINQ" здесь, в StackOverflow (Руководство для начинающих по LINQ), но имел следующий вопрос:

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

Итак, вопрос заключается в следующем: для простого извлечения данных, какой подход лучше, LINQ-to-SQL или хранимых процедур? Любые конкретные профи или con?

Спасибо.

ОТВЕТЫ

Ответ 1

Некоторые преимущества LINQ над sprocs:

  • Тип безопасности. Я думаю, мы все это понимаем.
  • Абстракция. Это особенно верно для LINQ to-Entities. Эта абстракция также позволяет фреймворку добавлять дополнительные улучшения, с которыми вы легко можете воспользоваться. PLINQ является примером добавления многопоточной поддержки LINQ. Изменения кода минимальны, чтобы добавить эту поддержку. Было бы намного сложнее сделать этот код доступа к данным, который просто вызывает sprocs.
  • Поддержка отладки. Я могу использовать любой отладчик .NET для отладки запросов. С sprocs вы не можете легко отладить SQL, и этот опыт в значительной степени связан с вашим поставщиком базы данных (MS SQL Server предоставляет анализатор запросов, но часто этого недостаточно).
  • Агент агностик. LINQ работает с большим количеством баз данных, и количество поддерживаемых баз данных будет только увеличиваться. Sprocs не всегда переносимы между базами данных, либо из-за различного синтаксиса, либо поддержки функций (если база данных поддерживает sprocs вообще).
  • Развертывание. Другие уже упомянули об этом, но проще развернуть одну сборку, чем развернуть набор sprocs. Это также связано С# 4.
  • Легче. Вам не нужно изучать T-SQL для доступа к данным, и вам не нужно изучать API доступа к данным (например, ADO.NET), необходимый для вызова sprocs. Это связано С# 3 и # 4.

Некоторые недостатки LINQ vs sprocs:

  • Сетевой трафик: sprocs нужно только сериализовать sproc-name и данные аргумента по проводу, в то время как LINQ отправляет весь запрос. Это может стать очень неудачным, если запросы очень сложны. Однако абстракция LINQ позволяет Microsoft со временем улучшать ее.
  • Менее гибкий: Sprocs может в полной мере использовать возможности базы данных. LINQ имеет тенденцию быть более общей в нем поддержкой. Это обычное явление в любой абстракции языка (например, С# vs ассемблер).
  • Перекомпиляция. Если вам нужно внести изменения в способ доступа к данным, вам необходимо перекомпилировать, выполнить версию и перераспределить сборку. Sprocs иногда позволяет администратору базы данных настраивать процедуру доступа к данным без необходимости перераспределять что-либо.

Безопасность и управляемость - это то, о чем люди тоже спорят.

  • Безопасность. Например, вы можете защитить свои конфиденциальные данные, ограничив доступ к таблицам напрямую и поместив ACL на sprocs. Однако с помощью LINQ вы можете ограничить прямой доступ к таблицам и вместо этого добавлять ACL в обновляемые представления таблиц для достижения аналогичного конца (при условии, что ваша база данных поддерживает обновляемые представления).
  • Управляемость. Использование представлений также дает вам преимущество в защите вашего приложения от изменений схемы (например, нормализации таблицы). Вы можете обновить представление, не требуя изменения кода доступа к данным.

Раньше я был большим парнем, но я начинаю склоняться к LINQ как лучшая альтернатива в целом. Если есть некоторые области, где sprocs явно лучше, то я, вероятно, все равно напишу sproc, но получаю доступ к нему с помощью LINQ.:)

Ответ 2

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

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

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

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

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

Ответ 3

Linq to Sql.

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

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

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

Ответ 4

Для базового поиска данных я бы без колебаний подумал о Linq.

Так как переход на Linq я нашел следующие преимущества:

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

Ответ 5

LINQ раздувает кеш процедур

Если приложение использует LINQ to SQL, а запросы связаны с использованием строк, которые могут сильно изменяться по длине, кэш процедур SQL Server будет раздуваться одной версией запроса для каждой длины строки. Например, рассмотрите следующие очень простые запросы, созданные в таблице Person.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

Ответ 6

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

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

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

LINQ делает истинное модульное тестирование невозможным, поскольку (на мой взгляд) он не прошел тест ACID.

Отладка в LINQ проще: Зачем? VS позволяет полностью входить от управляемого кода и регулярной отладки SP.

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

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

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

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

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

ИЗМЕНИТЬ: LINQ to SQL Хранимая часть процедуры - это то, что мне еще нужно прочитать больше - в зависимости от того, что я нахожу, я могу изменить свою вышеприведенную диарити;)

Ответ 7

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

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

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

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

Я думаю, вам нужно пойти с procs для чего-то реального.

A) Написание всей вашей логики в linq означает, что ваша база данных менее полезна, потому что ее может использовать только ваше приложение.

B) Я не уверен, что объектное моделирование в любом случае лучше, чем реляционное моделирование.

C) Тестирование и разработка хранимой процедуры в SQL - это намного быстрее, чем цикл редактирования компиляции в любой среде Visual Studio. Вы просто редактируете, F5 и выбираете, и вы уходите на гонки.

D) Легче управлять и развертывать хранимые процедуры, чем сборки. Вы просто кладете файл на сервер и нажимаете F5...

E) Linq to sql по-прежнему пишет дерьмовый код в моменты, когда вы этого не ожидаете.

Честно говоря, я думаю, что конечной задачей MS было бы увеличить t-sql, чтобы он мог объединить проекцию в буквальном смысле так, как это делает linq. t-sql должен знать, хотите ли вы, например, сделать order.lineitems.part.

Ответ 13

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

Ответ 14

Также существует проблема возможного откат 2.0. Поверьте мне, что это случилось со мной пару раз, поэтому я уверен, что это случилось с другими.

Я также согласен с тем, что абстракция лучше. Наряду с тем, что первоначальная цель любой ORM заключается в том, чтобы РСУБД хорошо сочеталась с концепциями ОО. Однако, если все работало отлично, прежде чем LINQ, чтобы немного отклониться от концепций OO, закрутите их. Концепции и реальность не всегда хорошо сочетаются. В ИТ нет места для воинствующих фанатиков.

Ответ 15

Я предполагаю, что вы имеете в виду Linq To Sql

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

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

Ответ 16

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

Как вывод, выбор между мотоциклом или автомобилем зависит от вашего маршрута (бизнеса), длины (времени) и пассажиров (данных).

Надеюсь, что это поможет, я могу ошибаться.: D

Ответ 17

Все эти ответы, ориентированные на LINQ, в основном говорят о EASE of DEVELOPMENT, которая более или менее связана с низким качеством кодирования или лени в кодировании. Я всего лишь.

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

Снова TypeSafety, предостерегаем, что "мы стараемся избегать неправильного приведения типов", которое опять-таки низкого качества мы пытаемся улучшить с помощью linq. Даже в этом случае, если что-либо в базе данных изменяется, например. размер столбца String, тогда linq нужно перекомпилировать и не будет видовым без этого. Я пробовал.

Несмотря на то, что мы нашли хорошее, приятное, интересное и т.д., работая с LINQ, у него есть недостаток в сдвиге, который делает разработчик ленивым:), и это доказано в 1000 раз, что это плохо (может быть хуже) по производительности по сравнению со Stored Procs.

Перестаньте лениться. Я стараюсь.:)

Ответ 19

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

Ответ 20

Для простых операций CRUD с одной точкой доступа к данным, я бы сказал, для LINQ, если вам удобно с синтаксисом. Для более сложной логики я думаю, что sprocs более эффективны по производительности, если вы хорошо разбираетесь в T-SQL и более продвинутых операциях. У вас также есть помощь от Tuning Advisor, SQL Server Profiler, отладки ваших запросов от SSMS и т.д.

Ответ 21

Результат можно суммировать как

LinqToSql для небольших сайтов и прототипов. Это действительно экономит время для прототипирования.

Sps: Universal. Я могу точно настроить свои запросы и всегда проверять ActualExecutionPlan/EstimatedExecutionPlan.

Ответ 23

Оба LINQ и SQL имеют свои места. Оба имеют свои недостатки и преимущества.

Иногда для сложного поиска данных вам может потребоваться сохранение procs. И иногда вы можете захотеть, чтобы другие люди использовали ваш сохраненный proc в Sql Server Management Studio.

Linq to Entities отлично подходит для быстрой разработки CRUD.

Конечно, вы можете создавать приложение, используя только тот или иной. Или вы можете смешать его. Все сводится к вашим требованиям. Но SQL-хранимые procs не исчезнут в ближайшее время.