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

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

1. Безопасность типа: Я думаю, мы все это понимаем.
2. Абстракция: это особенно верно для LINQ-to-Entities . Эта абстракция также позволяет фреймворку добавлять дополнительные улучшения, которыми вы можете легко воспользоваться. PLINQ - это пример добавления многопоточной поддержки к LINQ. Изменения кода минимальны для добавления этой поддержки. Было бы MUCH сложнее сделать этот код доступа к данным, который просто вызывает sprocs.
3. Поддержка отладки: я могу использовать любой отладчик .NET для отладки запросов. С помощью sprocs вы не можете легко отладить SQL, и этот опыт в значительной степени связан с поставщиком базы данных (MS SQL Server предоставляет анализатор запросов, но часто этого недостаточно).
4. Vendor agnostic : LINQ работает с большим количеством баз данных, и число поддерживаемых баз данных будет только увеличиваться. Sprocs не всегда переносятся между базами данных, либо из-за различного синтаксиса, либо из-за поддержки функций (если база данных вообще поддерживает sprocs).
5. Deployment: другие уже упоминали об этом, но проще развернуть один assembly, чем развернуть набор sproc. Это также связано с #4.
6. Проще : вам не нужно изучать T-SQL, чтобы получить доступ к данным, и не нужно изучать доступ к данным API (например, ADO.NET), необходимый для вызова sprocs. Это связано с #3 и #4.

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

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

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

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

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

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

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

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

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

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

Linq to Sql.

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

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

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

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

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

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

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

Если приложение использует LINQ - SQL и запросы включают использование строк, которые могут быть сильно изменяемыми по длине, кэш процедур сервера SQL будет раздут одной версией запроса для каждой возможной длины строки. Например, рассмотрим следующие очень простые запросы, созданные для таблицы 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: одна связана с NVARCHAR(7), а другая с NVARCHAR(11). Теперь представьте, что существуют сотни или тысячи различных входных строк, все с разной длиной. Кэш процедур стал бы излишне заполнен всевозможными различными планами для одного и того же запроса.

Подробнее здесь: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код хранимых процедур против (предыдущие обсуждения)

Для простых операций CRUD с одной точкой доступа к данным я бы сказал перейти на LINQ, если вы чувствуете себя комфортно с синтаксисом. Для более сложной логики я думаю, что sprocs более эффективны с точки зрения производительности, если вы хорошо разбираетесь в T-SQL и его более продвинутых операциях. Вы также можете воспользоваться помощью Помощника по настройке, SQL Server Profiler, отладкой ваших запросов от 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 есть свои места. И то, и другое имеет свои недостатки и преимущества.

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

Linq к сущностям отлично подходит для быстрого развития CRUD.

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