Linq (Linq to SQL, EF) может фильтровать локальные (клиентские) коллекции, а так же формировать серверные SQL запросы. В Вашем случае с большим набором данных первое неприемлемо.
Следовательно, остаётся выбор за SQL. Если Linq-запрос написан грамотно (который потом транспонируется в SQL), то без разницы, что быстрее. Потому что тот же сгенерённый запрос можно было написать руками в той же хранимой процедуре.
А, вообще, всё зависит от сложности запроса.

КурдльKonstantin S.B.Хранимые процедуры

Объясните мне, пожалуйста, как хранимые процедуры могут быть производительнее прямых запросов к БД?

Про процедурный кэш слыхали чё?

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

Konstantin S.B.В отдельных случаях, это может способствовать ее снижению, когда план выполнения стоило бы поменять. :)
Разумеется. Но меня спрашивали "как хранимые процедуры могут быть производительнее" :)

КурдльИ как это соотносится с производительностью автоматизированной системы, в состав которой входит СУБД?
Что значит "как это соотносится с производительностью"? Напрямую соотносится.

КурдльНе теряется время на синтаксический разбор SQL-запросов? Вы серьезно в это верите?
Не верю, а знаю.
P.S. Не забывайте еще и про оптимизацию и компиляцию. Это тоже немаловажный cost.

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

Производительность хранимых процедур MS SQL Server 2000

http://www.rusdoc.ru/articles/9513/

КурдльМСУ,

Могли бы привести квинтессенцию "исследования" по приведенной Вами ссылке:

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

Вы же сами привести квинтессенцию, зачем мне её приводить? :)

привести == привели

off: Курдль, а почему я захожу на Ваш профильный сайт, а меня редиректит на какой-то левый порносайт?

DatarНе кидайте тонны флейма
Где тут тонна флейма? Я Вам привёл ссылку. Что ещё нужно?
P.S. Вы провели тестирование по указанному материалу? К какому результату пришли?

Datarполучается как с тем богом, все в него верят, а доказательств нету.
Когда приложитесь умом к той статье, которую я дал - доказательства будут. А трепать языком из-под забора все могут, тут много ума не нужно.
P.S. По делу всё, как я понял?

Datarхапэ увеличивают время разработки и сложность сопровождения системы.
На счёт времени разработки не слогласен. Какая разница, где написать тот или иной пусть сложный батч, на стороне сервера или на клиенте сервера? На счёт сопровождения системы - тоже. В чём сложность развернуть схему данных в БД с хранимыми процедурами?
Вижу реальных два недостатка хранимых процедур - они не поддаются нормальной документации. По C# коду можно автогенерировать достаточно качественные доки, хотя есть тулзы и для генерации тех же chm-хелпов и для sql-серверных объектов. Второе - в случае поддержки приложением нескольких видов SQL-серверов (+ORM) хранимые процедуры будут, действительно, тяжелой ношей. Других страхов в отношении хп не вижу.

DatarВыигрыш в скорости если и есть, то на глаз в решаемых мной задачах не наблюдается.
Ну так не те задачи Вы решали, видимо.

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

DatarА вы сами пробовали приложится? Хотябы к последнему обзацу?
Пробовал. И?

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

DatarНе красиво как-то, искать изъяны к других, не замечая их в себе ;-)
А кто их ищет-то, если они навиду?

DatarПо теме у меня все, если только у вас опять не прорвется нечто личностное.
Личностное опустим, меня больше интересует именно по делу.

Курдль1. Поверьте моему опыту - усложняют катастрофически!
Да ничего они не усложняют, если Вы умеете писать качественный нормальный сиквел код :)

КурдльХорошо спроектированная БД максимально приближена к структуре, сущностям, связям предметной области. ХП "вашего типа" накладывают суррогатные ограничения на естественный доступ к данным БД. Либо пытаются скрыть огрехи в проектировании БД.
Бред человека, идущего в потьмах. Не в обиду, дружище :) Мы с Вами ни раз уже дискутировали по разным направлениям, но такого похабного заявления я от Вас не ожидал, ей Богу...

КурдльБлагодарное, если понимать, какие цели стоят под приложением. Подменять "хранимой процедурой с одним запросом" один запрос, как указано в вышеприведенных ссылках, - смехотворно.
Абсолютно согласен. Для этого очень удобно применять ORM. Но иногда приходится жертвовать собою и выносить реально сложную обработку данных (где используются и работа с линкед серверами, и толкание DTS/SSIS пакетов, и т.д.) именно в хранимые процедуры. Задачи, ведь, бывают и посложнее, чем проапдейтить табличку по условию.

LRменьше свободы - больше надежности и управляемости, больше свободы - меньше надежности и управляемости...
Очень красиво сказали, +1

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

Datar, я уже ответил на этот потуг, изволю не повторяться.

Datar'чик, я для Вас придумал хороший наглядный вариант, пищу для мозгов.
Но для начала Вы опишите мне, как будете решать такую задачу:

Дано: MS SQL Server 2005, .NET клиент (не важно, веб или вин), ORM: NHibernate
Задача: удалить множество записей из таблицы Northwind..Categories (значения ID заранее известны)

Я жду от Вас решения, пишется минимум кода. А потом я покажу, где Вы были не правы :)

Будем рассматривать прежде всего - вопросы оптимизации конечного сиквел кода.

Готовы? Или сразу сдадитесь? )

netivanвсего лишь для удобства вызова ХП и получения результата.
Пестец...

netivanя вас ждал )). Тем не менее на вопрос никто не ответил :(
Ну уж, звиняйте, netivan, какой вопрос - такой и ответ :)

P.S. Юзать ORM ради "удобства вызова ХП" это, простите, дико )

netivanТем не менее на вопрос никто не ответил :(
Хотите диких скоростей - юзайте ридеры, вот Вам мой ответ.

buredС ХП наоборот были некоторые неудобства, по-крайней мере в EF.
Как дела в EF4 пока не прояснял.

Год назад трещали.

netivanя боялся такого ответа. Только понять не могу каким образом Линк может затормозить?
Кодогенерация, типизация. Детский сад, netivan, ей Богу... :(

netivanхз в Linq2Sql неудобств не замечал :) Вообщем не нашел я поддержки !!
Да, у Linq2Sql с этим проблем нет.