Для начала прочтите прошлогодний опыт
http://www.1cpp.ru/forum/YaBB.pl?num=1226039405

Критика решения из #14

SELECT @РезБло = 1
FROM dbo._1SBKTTLC AS ТабБло WITH (TABLOCKX, HOLDLOCK)
 

тем самым вы наложили блокировку на всю талицу _1SBKTTLC
т.е ни о каком "Как обойти блокировку таблицы _1SBKTTLC?" не может быть и речи
до конца транзакции остальные проведения ждут.

т.к @РезБло = 1 то оператор просто лишний

IF @РезБло <> 1
ROLLBACK TRAN
 

Ваше решение дает выигрыш за счет локал свертки.
Т.е поясню предположим есть 100 строк с проводками документ проведен.
Вы меняете только одну строку . например сумму со 100 до 150
В вашей итоговой таблице останется только одна ненулевая строка с суммой 50. Предполагается что документ дает теже самые проводки.
и только будет одна строка изменяющая итоговую таблицу _1SBKTTLC.
За счет этого и выигрыш. но при этом все блокируется.
Еще большего выигрыша можно достичь переписав #14 без курсора и в доп таблицу добавив @@SPID

classic писал(а) 24. Сентября 2009 :: 06:05:

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

Тогда получается следущее : итоги Вам надо получать не по одной таблице а по двум.
А во вторых предположим что есть документ в нем 100 строк
и 100 проводок.
Я этот документ ничего не меняя перепроведу 200 раз ( зачем не спрашивайте ) тогда в доп таблице
у нас будет 200*100*2 = 40 000 лишних строк которые в сумме будут давать 0.
При массовой работе (по крайней мере у нас ) в документы записывается потом всякий мусор с точки зрения проводок,движений.
Какой нибудь комментарий, назначение платежа,фио водителя,
номер машины и.т.д доп свебения о товаре реальной отгрузке.

Опять же вопрос когда Вы считаете итоги по новому алгоритму Вы эту доп таблицу блокируете или нет ? (проблема грязного чтения )

Z1 писал(а) 24. Сентября 2009 :: 05:29:


1. Уточню:
индекс до изменений состоит из:

[PERIOD] ASC,
[SP1] ASC,
[SP2] ASC,
... 

индекс после изменений:

[PERIOD] ASC,
[SP1] ASC,
[SP2] ASC,
...
[ROW_ID] ASC 

.
2. Пробовал посмотреть статистику выполнения простого запроса (смотри вложение _03), где сверху до изменений (без ROW_ID), внизу с ROW_ID. Да есть "падение", но это десятые милисекунды. Не уж то это и есть "скорость поиска итогов очень
сильно упадет"?

Z1 писал(а) 24. Сентября 2009 :: 05:29:


Зачем? Ну чесно, не понимаю зачем переписывать запросы? Все запросы к регистру (к RG):
- имеют условие на [PERIOD];
- все имеют агрегацию по измерениям.

Z1 писал(а) 24. Сентября 2009 :: 05:29:


Да буду вынужден, что бы перестраховатся. Сворачивание итогов будет происходить в час миним нагрузки на БД, ночю к примеру.

chicago писал(а) 24. Сентября 2009 :: 07:16:

и это работает даже для баз sql200 ?

Z1 писал(а) 24. Сентября 2009 :: 07:17:


Не могу утверждать с уверенн. 100% что всегда, но pvase это удалось "схрестить", чем я и успешно пользуюсь по сей день.
А также там есть аналог BOL, даже на рус. языке (при том что он и обновляем). Не идеал., но во многом лучший инстр. чем тот что в поставке с MS SQL Server 2000.