
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
25.07.2002, 18:54:39
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
В случае сложных запросов ответ очевиден - хранимые процедуры. Но если нужно выполнить всего лишь один запрос типа INSERT INTO table VALEUS(...) ? Лучше это оформить как хранимую процедуру или выполнить ее как обычый запрос? Спрашиваю потому, что меня пытались убедить, что хранимые процедуру рулят в любом случае. Так ли это? И если все таки "да", то откуда береться выигрыш в скорости? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:05:12
|
|||
|---|---|---|---|
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
ХП выполняются на чьей стороне? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:21:46
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
> ХП выполняются на чьей стороне? Точно не скажу, но по всей видимости на стороне сервера... А что могут и у клиента? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:35:18
|
|||
|---|---|---|---|
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
В общем случае ХП предпочтительнее. Все ad hoc запросы (те, что приходят из приложения, типа SELECT'ов, INSERT'ов в ASP) должны быть 'обработаны' сервером до выполнения, ХП же подвергаются такой обработке только один раз (если не принять специальных мер, конечно) и вылавливаются их кэша. Так вот. Плюс еще ХП решают проблемы с безопасностью, централизацией логики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:36:31
|
|||
|---|---|---|---|
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
и(з) кэша ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:44:08
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
jimmers Спасибо, объяснение весьма логичное, а можно по подробнее про: > ХП решают проблемы с безопасностью, централизацией логики. Просто не могу представить ситуацию, в которой ХП была бы безопаснее обычных запросов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:48:32
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
2 BioByte Просто не могу представить ситуацию, в которой ХП была бы безопаснее обычных запросов... Не пытайся себе это представить !!! Ты счастлтвый человек - оставайся им ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:49:44
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
Как я только по клаве не промахнулся.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 19:53:33
|
|||
|---|---|---|---|
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
Ну как же, можно выдать право на исполнение только определенных процедур в БД данному Пользователю. А в процедурах делать только то, что Вам необходимо, лишая Таким образом Пользователя возможности “навредить”. Второй аспект – это то, что пользуясь хранимыми процедурами и т.н. parameterized commands, можно забыть про проблемы, связанные со вставкой вредоносного кода в Ваши запросы (конечно, при условии, что внутри процедуры нет динамических запросов, как в недавнем примере от Деда Маздая) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 21:44:48
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
Данные устарели. Ещё с версии SQL7.0 нет большой разницы в том, что выполнять, ибо есть кэш последних запросов. Но с точки зрения концептуальной - все изменения в БД должны проходить только через SP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.07.2002, 23:45:57
|
|||
|---|---|---|---|
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
2Akzhan Соглашусь с Вами лишь отчасти: кэшируются только те ad hoc запросы, которые совпадают ‘посимвольно’. Я же имел ввиду, что параметризованные ad hoc запросы (то бишь те, у которых есть параметр, меняющийся от запроса к запросу – именно такие запросы чаще всего и используются) будут парситься и компилироваться при каждом изменении значения параметра, а вот ХП – нет (конечно, есть исключения). P.S. Об этом неплохо рассказано в книге “Inside Microsoft SQL Server 2000 / Kalen Delaney”, а также в статях на sqlmag.com Удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.08.2002, 18:38:02
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
При вставке данных посредством вызова хранимой процедуры с множеством входных параметров (а для INSERT INTO так и бывает) производительность этой конструкции из клиентской программы оказывается существенно ниже, чем выполнение готовой строки sql - INSERT INTO ... VALUES ..., в которой все входные данные уже подставлены в текст и требуется только выполнение команды. Это легко проверить, если выполнить около 1000 вызовов в цикле для хр. процедуры и готового sql, разница может быть в 2-3 раза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.08.2002, 18:54:23
|
|||
|---|---|---|---|
|
|||
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
Я был свидетелем противоположного результата (SQL 7.0, NT4). При добавлении множества записей в таблицу шустрее работали SP нежели отдельные запросы INSERT. Теперь стараюсь всё в SP запихивать ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.08.2002, 19:00:13
|
|||
|---|---|---|---|
"Plain query" или "Stored Procedure" Что эффективнее? |
|||
|
#18+
Это легко проверить, если выполнить около 1000 вызовов в цикле для хр. процедуры и готового sql, разница может быть в 2-3 раза. Лично у меня такой эффект наблюдался когда в процедуре не было SET NOCOUNT ON. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=46&tablet=1&tid=1821305]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
63ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 235ms |
| total: | 424ms |

| 0 / 0 |
