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

https://stackoverflow.com/questions/14530

08-06-2019
|

Вопрос

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

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

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

Спасибо.

Решение

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

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

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

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

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

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

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

Другие советы

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

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

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

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

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

Linq для Sql.

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

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

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

Для базового извлечения данных я бы без колебаний выбрал Linq.

С момента перехода на Linq я обнаружил следующие преимущества:

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

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

Если приложение использует LINQ to 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 ?Идентификатор обратной связи=363290

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дело в том, что когда речь идет об одной таблице базы данных и небольшом наборе 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;Если там миллион строк, это хит.Конечно, опытный пользователь не будет использовать этот способ для выполнения этой работы, но суть в том, что таким образом так легко сорваться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надеюсь, это поможет, возможно, я ошибаюсь.:D

Все эти ответы, склоняющиеся к LINQ, в основном говорят о ПРОСТОТЕ РАЗРАБОТКИ, которая в большей или меньшей степени связана с низким качеством кодирования или ленью в кодировании.Только я такой и есть.

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

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

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

Перестань быть ленивым.Я очень стараюсь.:)

Сохраненные процедуры в сравнении с кодом (Предыдущее обсуждение)

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

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

Результат можно резюмировать следующим образом

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

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

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

И LINQ, и SQL имеют свои места.И то, и другое имеет свои недостатки и преимущества.

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow