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

1. Быстродействие. Передача параметров происходила намного "легче", нежели запросов.
2. Не нужно было быспокоиться на клиентской части, что будут переданы в запросе некорректные данные, которые могли повлиять на сам запрос.
3. Транзакции
4. Многократное использование сторедпроцедуры.

В ADO.NET наверное единственным из преимуществ осталось только быстродействие; когда обращение к БД не очень активное, им можно наверное вообще пренебречь.
За корректность запроса можно заставить отвечать SqlCommand; транзакции используются прямо в коде (хотя и клиентские); многократное использование — обрамляем в метод и заставляем возвращать его необходимый набор данных как и со сторедпроцедурами...

Какой резон возиться со сторедпроцедурами?
Кто что об этом думает?

Здравствуйте, oRover, Вы писали:

R>Кто что об этом думает?

Мне, лично, кажется что между stored procedure и .net кодом работащем на той же машине где SQL Server, и как следствие пользующегося shared memory соединением, разницы в производительности быть не должно. А с точки зрения программирования, на .net сильно проще работать с построение сложных запросов, да и не надо между языками переключаться. Вообщем, мне кажется, что stored procedures, в форме тригеров, только для тригеров и нужны.

Если я не прав, скажите где?

-zork

Hello, "oRover"
> Использование сторедпроцедур в ADO было оправданным по многим причинам:
>
> 1. Быстродействие. Передача параметров происходила намного "легче", нежели запросов.
> 2. Не нужно было быспокоиться на клиентской части, что будут переданы в запросе некорректные данные, которые могли повлиять на сам запрос.
> 3. Транзакции
> 4. Многократное использование сторедпроцедуры.
>

5. Безопасность. Пользователю достаточно предоставить право на вызов SP. Таблицы, которые будет при этом задействованы для него могут быть не доступны.

> В ADO.NET наверное единственным из преимуществ осталось только быстродействие; когда обращение к БД не очень активное, им можно наверное вообще пренебречь.
> За корректность запроса можно заставить отвечать SqlCommand;

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

> транзакции используются прямо в коде (хотя и клиентские); многократное использование — обрамляем в метод и заставляем возвращать его необходимый набор данных как и со сторедпроцедурами...
>

сегодня данные в БД могут храниться в одном виде, завтра в другом. Использование SP позволяет абстрагироваться от этого.

Здравствуйте, ZORK, Вы писали:

ZOR>Здравствуйте, oRover, Вы писали:

R>>Кто что об этом думает?

ZOR>Мне, лично, кажется что между stored procedure и .net кодом работащем на той же машине где SQL Server, и как следствие пользующегося shared memory соединением, разницы в производительности быть не должно.
Должно. Есть неизбежные накладные расходы на вызов SQL. Если вся процедура — это одна строка select sum(amount) from moves where movedate between @d1 and @d2, то ессно ничуть не хуже сработает прямой вызов селекта (естественно, с точностью до прав доступа, как верно отметил ТК).
А если в сторед процедуре выполняется много запросов, то прямые их вызовы с перегонкой данных туда-сюда запросто просадят производительность в разы. Даже через shared memory.

Здравствуйте, TK, Вы писали:

TK>Hello, "oRover"
>> Использование сторедпроцедур в ADO было оправданным по многим причинам:
>>
>> 1. Быстродействие. Передача параметров происходила намного "легче", нежели запросов.
>> 2. Не нужно было быспокоиться на клиентской части, что будут переданы в запросе некорректные данные, которые могли повлиять на сам запрос.
>> 3. Транзакции
>> 4. Многократное использование сторедпроцедуры.
>>

TK>5. Безопасность. Пользователю достаточно предоставить право на вызов SP. Таблицы, которые будет при этом задействованы для него могут быть не доступны.

согласен, упустил.

>> В ADO.NET наверное единственным из преимуществ осталось только быстродействие; когда обращение к БД не очень активное, им можно наверное вообще пренебречь.
>> За корректность запроса можно заставить отвечать SqlCommand;

TK>Все пользователи в наше время просто душки, и даже не думают о том, что-бы получить доступ к БД напрямую (а посмотреть конфиденциальные данные или просто заняться вредительством — такое вообще только в страшном сне бывает).

ну это к безопасности

>> транзакции используются прямо в коде (хотя и клиентские); многократное использование — обрамляем в метод и заставляем возвращать его необходимый набор данных как и со сторедпроцедурами...
>>

TK>сегодня данные в БД могут храниться в одном виде, завтра в другом. Использование SP позволяет абстрагироваться от этого.

т.е.? Ты думаешь, что завтра MS SQL не будет поддерживать запросы?

Здравствуйте, oRover, Вы писали:

TK>>сегодня данные в БД могут храниться в одном виде, завтра в другом. Использование SP позволяет абстрагироваться от этого.

R>т.е.? Ты думаешь, что завтра MS SQL не будет поддерживать запросы?

Запросы он поддерживать будет, вот только в случае, если изменится структура таблиц — придется менять приложение. А так достаточно будет изменить SP

Здравствуйте, oRover, Вы писали:

хъ

ХР
— проще администрировать и сопровождать.
— проще отлаживать
— как минимум не уступают по производительности запросам в коде, так как любой ad hoc запрос превращается в sp_executesql. Если в запросе не используются параметры — вообще труба. Сервер будет каждый раз строить план.
— должен писать квалифицированный разработчик/DBA, а не прикладной программист
— компилируются, в отличие от запросов
— это дополнительный уровень косвености

Здравствуйте, TK, Вы писали:

TK>Здравствуйте, oRover, Вы писали:

TK>>>сегодня данные в БД могут храниться в одном виде, завтра в другом. Использование SP позволяет абстрагироваться от этого.

R>>т.е.? Ты думаешь, что завтра MS SQL не будет поддерживать запросы?

TK>Запросы он поддерживать будет, вот только в случае, если изменится структура таблиц — придется менять приложение. А так достаточно будет изменить SP

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

Здравствуйте, Alexey Shirshov, Вы писали:

AS>Здравствуйте, oRover, Вы писали:

AS>хъ

AS>ХР
AS> — проще администрировать и сопровождать.
AS> — проще отлаживать
AS> — как минимум не уступают по производительности запросам в коде, так как любой ad hoc запрос превращается в sp_executesql. Если в запросе не используются параметры — вообще труба. Сервер будет каждый раз строить план.
AS> — должен писать квалифицированный разработчик/DBA, а не прикладной программист
AS> — компилируются, в отличие от запросов

кто, ХР? где можно почитать об этом? Я всегда думал, что они просто выполняются как запросы....

AS> — это дополнительный уровень косвености

Здравствуйте, oRover, Вы писали:

R>Использование сторедпроцедур в ADO было оправданным по многим причинам:

R>1. Быстродействие. Передача параметров происходила намного "легче", нежели запросов.
R>2. Не нужно было быспокоиться на клиентской части, что будут переданы в запросе некорректные данные, которые могли повлиять на сам запрос.
R>3. Транзакции
R>4. Многократное использование сторедпроцедуры.

R>В ADO.NET наверное единственным из преимуществ осталось только быстродействие; когда обращение к БД не очень активное, им можно наверное вообще пренебречь.
R>За корректность запроса можно заставить отвечать SqlCommand; транзакции используются прямо в коде (хотя и клиентские); многократное использование — обрамляем в метод и заставляем возвращать его необходимый набор данных как и со сторедпроцедурами...

R>Какой резон возиться со сторедпроцедурами?
R>Кто что об этом думает?

Пример из жизни. Написал запрос, который после долгих мучений возвращает данные из 14 таблиц(потом все это загружается в DataSet). Один такой запрос в виде батча в QA выполнялся 300 мс. Потом оформил весь это батч в виде ХП. И эта ХП выполнялась 30 мс. Я думаю этого достаточно, что выбор пал на ХП. Более того — я не горю желанием в коде бизнес сервера писат SQL запрос строк эдак на 250.

Кроме того, ХП — это уровень абстракции, с которым очень удобно работать.

Здравствуйте, oRover, Вы писали:

R>Использование сторедпроцедур в ADO было оправданным по многим причинам:

R>1. Быстродействие. Передача параметров происходила намного "легче", нежели запросов.

1. Я сильно сомневаюсь, что бы параметры процедуры передавались на сервер неким отличным от обычных запросов способом. Для InterBase, например, никакой половой разницы нет.
   
2. Существуют целая куча различных "универсальных" способов вызова хранимых процедур (ODBC,ADO,ADO.NET). И конвертирование из "универсального" вызова в "native" может приводить к гораздо большим накладным расходам, чем выполнение обычного параметризованного запроса.

Короче, происхождение вывода о быстродействии (в контексте ADO) мне не понятно