LINQ-запросы против хранимых процедур

Question

Каковы плюсы и минусы использования запросов linq (вместе с ORM, например EF или linq2sql) VS.Хранимые процедуры (SQL Server 2008) для запроса и обновления модели данных?Спектакль?Скорость?Etc ...

Answer 1

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

var query = from c in db.TableName
            where c.Name == "foo"
            select c;

, который точно сообщает, какие данные извлекаются.

С другой стороны, хранимые процедуры не требуют перекомпиляции приложения, если вы решили изменить код.Если вы решите внезапно изменить предложение "where" или изменить Order By - изменить звездочку легко.Изменение кода Linq может занять больше времени.

Я уверен, что их гораздо больше, но я заметил, что это два.

Answer 2

Есть 2 лагеря: для сохраненных процедур и против сохраненных процедур.

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

На практике

• , если вы являетесь корпоративным программистом, вы никогда не измените свою платформу RDBMS.Вы каждый раз реорганизуете своего клиента, и вы переопределяете свой DAL / репозиторий.Зачем?Используйте хранимые процедуры.
• , если вы работаете на поставщика, то вам, вероятно, придется поддерживать несколько RDBMS.ORM в основном это абстрагирует.

Я в корпоративном магазине, так что ...

• Плюсы: с Linq вам не нужно знать SQL
• Минусы: вы облажались, когда что-то идет не так

Нам (как команде разработчиков DBA) часто приходится помогать пользователям ORM в сестринских командах.

Естьтакже более тонкие проблемы, такие как:

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

Answer 3

@ gbn - отличный ответ.

В огромных системах с сотнями миллионов записей манипулирование данными на уровне представления просто не снизит его Приложения, интенсивно использующие данные (не приложения для ведения блогов!), Будут масштабироваться раньше, чем вы думаете.

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

Также важно помнить, что синтаксис SQL был последовательным на протяжении более 20 лет. Если это не важно для вас, вы недостаточно долго программировали.

Answer 4

Реальный ответ - это «лошади для курсов». С одной точки зрения (как db dev, как @gbn), он хранится полностью. С моей точки зрения, как сквозного веб-разработчика бэк-офиса, у которого параллельное использование приложения никогда не превышает 100, и кто не блестящ в написании эффективного SQL, это LINQ (в настоящее время EF 4.1). И сначала код, если я могу сойти с рук. Это 15-я статья, которую я прочитал сегодня по этому вопросу (после ссоры на совещании разработчиков), и каждая статья предлагает одно и то же - «лошади для курсов». И иногда, в мире бэк-офиса, нужно учитывать не только эффективность извлечения данных, но и то, насколько быстро (эффективно) вы можете исправлять ошибки и насколько легко (эффективно) следующий человек может видеть, что вы код делает. С этой точки зрения LINQ побеждает.

Answer 5

Я бы почти всегда использовал хранимые процедуры по нескольким причинам:

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

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

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

Answer 6

Многое было сказано уже в ответ на оригинальный вопрос. Мой ответ основан на коммерческих аспектах, а не технических. Вот мой опыт, возможно, он даст некоторые советы для тех, кто начинает новые проекты. Мы начали с Asp.net + SQL Server, и приложение превратилось в сложное приложение с использованием около 800 хранимых процедур. В течение трех лет мы запускаем бесплатный SQL-сервер через программу Microsoft, поэтому никогда не обращали на это внимания. Когда в таблицу попало лицензионное предложение размером более 50 КБ (оно основано на количестве ядер / потоков и вам также нужна отдельная лицензия для подчиненного сервера), мы приступили к переходу на MySQL. Жаль, что мы не использовали хранимые процедуры. Без хранимых процедур мы могли бы легко мигрировать в течение нескольких дней. Нам потребовалось гораздо больше времени и усилий, чтобы переписать SP в MySQL. Если вы не используете SP, ваше приложение более гибкое и переносимое, и вам будет проще отлаживать код внутри самого приложения.

Так что, если не технический, с коммерческой точки зрения есть веские аргументы против использования хранимых процедур в веб-приложениях. Если вы не используете SP, вы можете также распространять ваше приложение среди клиентов со схемой БД (которая будет включать только таблицы), в то время как логика вашего приложения все еще скрыта в Linq + EF или Linq SQL.

Answer 7

Ложная дихотомия.IMO, вы можете получить лучшее из обоих, используя необработанный SQL (который является важным навыком, от которого мы не должны уклоняться) с инструментами, которые просто делают это удобным.Хранимые процедуры вводят некоторые проблемы связывания / развертывания (время и т. Д.), Которые большинству людей не нужны;ORM могут быть неэффективными.Большинство людей не собираются менять СУБД (и если они это сделают, это будет серьезный проект в любом случае), поэтому: я большой поклонник параметризованного командного текста.И инструменты, которые помогают, например, dapper.

Другой пользователь опубликовал пример фильтрации LINQ по имени;хорошо, вот то же самое в dapper:

string name = ...
var list = connection.Query<YourType>(
    "select * from TableName where Name=@name",
    new { name }).ToList();

Полностью параметризованный;сильно оптимизирован;безопасный;быстрый;очистить;легко получить право.Работа выполнена.

Answer 8

Не совсем ответ на ваш вопрос, но не забывайте, что вы все равно можете использовать EF для хранимых процедур

Answer 9

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

В дополнение к комментариям Питера, вот еще несколько:

1. EF или Linq-to-SQL (или NHibernate тоже) являются ORM, что означает, что они хотят превратить строку в вашей таблице базы данных в объект. Поскольку этот объект обычно должен содержать все значения из этой таблицы (или даже из нескольких таблиц, в случае EF), эти ORM обычно используют подход SELECT * FROM ..... Это означает: поскольку вы выбираете все столбцы, вы обычно не можете использовать какие-либо индексы покрытия, и ваша производительность будет ухудшаться. Это классический компромисс между удобством и производительностью

2. Все известные мне ORM, с которыми я работал, в основном нуждаются в полном доступе к базовым таблицам . Это большое нет-нет для многих предприятий и их администраторов баз данных. Разумно используя хранимые процедуры, вы можете обойтись без необходимости предоставления всем пользователям доступа к базовой таблице - большой плюс с точки зрения безопасности доступа!

Answer 10

Это зависит от используемой вами версии SQL.План выполнения (то есть информация, используемая SQL для ускорения второго вызова ...) в SQL 2008 действительно хорошо работает и с O / RM.Я не понимаю, почему вы используете O / RM и тратите много времени, переопределяя все в пользовательский хранимый процесс.Также сохраненный процесс.вряд ли будет TDD и не позволяет вам понятие Единицы WOrk и транзакции