ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Можно ли существенно оптимизировать данную процедуру.
25 сообщений из 57, страница 2 из 3
  2  все
Можно ли существенно оптимизировать данную процедуру.
    #38304458
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
CammomileПример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию.
Выберите любую задачу, где важен _порядок_ обработки записей
...
Рейтинг: 0 / 0
20.06.2013, 11:57
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304466
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aleks2
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
CREATE PROCEDURE [dbo].set_default_descriptions @GID INT
AS 

SET NOCOUNT on;


	
	with 
	-- Получаем список характеристик по умолчанию категории - образца
	props as (
				SELECT p.P_ID, p.P_NAME, p.P_UNIT, ggp.GRP_SORT
				FROM TBL_GROUPS_GOODS_PROPS ggp inner join TBL_PROPS p on ggp.GRP_P_ID = p.P_ID
				WHERE ggp.GRP_GR_ID = (SELECT G_GR_ID FROM TBL_GOODS WHERE G_ID = @GID)
	)
	-- ну и все остальное
	merge TBL_GOODS_PROPS tgp
	  using( select *, @GID as GID from props) as p
	  on (tgp.GP_G_ID = p.GID AND tgp.GP_P_ID = p.P_ID)
	  when not matched by target then
	    insert (GP_G_ID, GP_P_ID, GP_UNIT) VALUES (p.GID, p.P_ID, p.P_UNIT)
	  when matched then
        UPDATE  SET GP_UNIT = p.P_UNIT
	  when not matched by source then
	    delete; -- ну, тут надо сообразить
...
Рейтинг: 0 / 0
20.06.2013, 12:00
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304470
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?
...
Рейтинг: 0 / 0
20.06.2013, 12:02
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304484
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
CammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу.
Да легко
Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G
Таблица
G - varchar
D - datetime
M - money
S - money
...
Рейтинг: 0 / 0
20.06.2013, 12:07
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304493
dimon71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimon71
Участник
Glory,

Разрешите и мне вставить свои 5 копеек, раз с меня началось.

Действительно. Все зависит от задачи.

Моя задача успешно решилась благодаря просмотру плана исполнения.

Признаю, сглупил, не разобрался, зря потревожил народ.

Оказалось виноват маленький триггерок, который логирует записи. В него затесался забытый запрос об обновлении одной ячейки. И стоимость то всего была 0,51%. Однако на большом количестве - вот и результат.

Просто в голову не пришло посмотреть. Лог и лог. Что там можно исправить.

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

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

Спасибо.
...
Рейтинг: 0 / 0
20.06.2013, 12:10
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304536
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Cammomileну вот же
DirksDRdimon71,

Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много.
Вряд ли в справочние товаров у Вас больше.
Проверьте наличие и использование индексов.
Использование курсоров не так уж критически сказывается на быстродействии.
Зато намного наглядней алгоритм(скрипт).

Ааа...

Ну использование курсоров на самом деле может очень существенно сказываться на производительности.

Причем, как ни странно, в обе стороны.

На счет наглядности я бы тоже поспорил — запросы читать проще, сразу все ясно, и объективно это проще, декларативная логика запроса описывает, что надо сделать, а не как и что надо сделать, так что можно сказать в двп раза проще понимать.
...
Рейтинг: 0 / 0
20.06.2013, 12:24
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304545
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
CammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?

Они действительно редки в бд.

Но я одну такую знаю — партионое списание товаров по FIFO или LIFO.
...
Рейтинг: 0 / 0
20.06.2013, 12:28
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304560
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
В данном случае наглядность и простота кода лучше.

Извини, наглядностью в твоем коде даже нее пахнет.

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

Чтобы писать на SQL особенно -то много спец. Образования и не надо,
Надо только знать, что надо писать запросы везде, где только возможно, использовать индексы и выделять серверу память под кэш.
...
Рейтинг: 0 / 0
20.06.2013, 12:34
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304572
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
dimon71В данном случае наглядность и простота кода лучше. Я, не имея специального образования, решил поставленную задачу с хорошим результатом.Конечно, нагладность и простота очень важны, и то, что задача решена - замечательно, но конкретно решение вашей задачи нагляднее и проще читается без курсоров.

Нужно комментарии на русском в процедуре записать на языке SQL в одном запросе, только и всего.
Просто для вас SQL не основной язык, вы к нему не привыкли, не чувствуете его.
...
Рейтинг: 0 / 0
20.06.2013, 12:37
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304578
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
MasterZivCammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?

Они действительно редки в бд.

Но я одну такую знаю — партионое списание товаров по FIFO или LIFO.
это частный случай нарастающего итога - той самой класической и одной единственной задачи (хотя и весьма распространенной) где курсор лучше.

Умрет с появлением инструкции:
update ....
from ...
order by ...
...
Рейтинг: 0 / 0
20.06.2013, 12:40
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304586
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
GloryCammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу.
Да легко
Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G
Таблица
G - varchar
D - datetime
M - money
S - money
1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами.
2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее.
...
Рейтинг: 0 / 0
20.06.2013, 12:41
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304596
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Cammomile2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее.
Он был еще в 2000. Только он не гарантирует порядок.
А именно про задачи завязанные на порядок обработки записей я и говорил.

Cammomile1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами.
Вы уже проверили это ?
...
Рейтинг: 0 / 0
20.06.2013, 12:43
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304666
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
Я спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы.

"Только он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения.
...
Рейтинг: 0 / 0
20.06.2013, 13:07
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304672
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
CammomileЯ спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы.
Ага. Слышал в вашего Карузо. Мне Рабинович напел

CammomileТолько он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения.
курсор не единственный способ получения такого нарастающего итога.
...
Рейтинг: 0 / 0
20.06.2013, 13:10
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304697
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
Ну там весьма авторитетный рабинович напел.

Так, вы сказали что есть случаи когда курсор быстрее аналогичного апдейта/селекта/ инсерта.
В вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор?
...
Рейтинг: 0 / 0
20.06.2013, 13:23
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304701
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
CammomileВ вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор?
Что значит НЕаналогичный ? update from join он и африке update
Или вы знаете другие команды обновления ?
...
Рейтинг: 0 / 0
20.06.2013, 13:25
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304736
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
Код: sql
1.
update t set f = 1 where d in (1,2,3)



аналогичный курсор который никак не может быть быстрее (типа того что делает автор топика)

Код: sql
1.
2.
3.
4.
5.
6.
7.
declare @d int 
declare cur cursor for select d from t where d in (1,2,3) 
fetch next from cur into @d
while @@fetch_status = 0 begin  
  update t set f=1 where d= @d 
  fetch next from cur into @d 
end
...
Рейтинг: 0 / 0
20.06.2013, 13:37
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304750
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Cammomile аналогичный курсор который никак не может быть быстрее (типа того что делает автор топик
Смешной вы. Вы под аналогией понимаете давайте выполнять массовый апдейт в цикле по одной записи ?
Вы заявили, что все курсоры обязательно должны быть переписаны в запросы.
Даже у автора темы идут какие-то рассчеты и проверки. И вы даже не знаете, можно ли их осуществить в вашем update t set f = 1 where d in (1,2,3)
...
Рейтинг: 0 / 0
20.06.2013, 13:43
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304846
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
17-77
Участник
dimon71,

можно оптимизировать, надо избавиться от курсора
...
Рейтинг: 0 / 0
20.06.2013, 14:26
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304847
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
Cammomile,

Best approaches for running totals
...
Рейтинг: 0 / 0
20.06.2013, 14:26
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304862
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
О годная аналитика. Сейчас почитаем.

Кстати, касаемо "стремного апдейта"

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

По мне так вполне надежно, не ?
...
Рейтинг: 0 / 0
20.06.2013, 14:32
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304914
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
CammomileМне кажется, что "не гарантирует порядка" больше спекуляция
1 - нет документированных случаев когда этот метод подвел бы
У вас есть документированный способ указания порядка обработки записей ?

Cammomile2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали
Это вы цитируете документацию ?

Cammomile3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты
Разговор не про саму конструкцию, про гарантированный порядок.
...
Рейтинг: 0 / 0
20.06.2013, 14:56
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304938
Фотография Shakill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shakill
Участник
CammomileО годная аналитика. Сейчас почитаем.

Кстати, касаемо "стремного апдейта"

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

По мне так вполне надежно, не ?такая логика для ответственных применений не годится. разработчики сервера вам ничего по поводу этой конструкции не обещают => слово "надежно" тут вообще не применимо. о чем и говорится в статье, кстати
I’ll re-state that I don’t believe this approach is safe for production, regardless of the testimony you’ll hear from people indicating that it “never fails.” Unless behavior is documented and guaranteed, I try to stay away from assumptions based on observed behavior. You never know when some change to the optimizer’s decision path (based on a statistics change, data change, service pack, trace flag, query hint, what have you) will drastically alter the plan and potentially lead to a different order
...
Рейтинг: 0 / 0
20.06.2013, 15:05
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304997
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
CammomileМне кажется, что "не гарантирует порядка" больше спекуляция
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 1
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 2
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 3
...
Рейтинг: 0 / 0
20.06.2013, 15:37
| Ответить | Цитировать | Написать  
Можно ли существенно оптимизировать данную процедуру.
    #38304998
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cammomile
Участник
Раз пошла такая пьянка- режь последний огурец !
...
Рейтинг: 0 / 0
20.06.2013, 15:38
| Ответить | Цитировать | Написать  
25 сообщений из 57, страница 2 из 3
  2  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Можно ли существенно оптимизировать данную процедуру.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&msg=38304697&tid=1706505]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 158ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 64ms
get tp. blocked users:
 2ms
others: 237ms
total:  504ms
созд. / загр.: 504ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]