Купил, наконец-то 8.2 - версию для обучения программированию. Читаю. Думаю. И натыкаюсь на такой пассаж:
Мы, в восьмерках, будем делать по новому: при списании со склада - вначале списывать, а потом проверять - не списали-ли мы лишнего. И если вдруг списали - тогда откатывать назад.
А в чем смысл, в чем выгода? Нафига это?
1. Вначале запросом получаем остатки товаров с себестоимостью.
2. Проводим.
3. Потом еще раз таким же запросом - ищем отрицательные остатки.
Так же дольше? На один запрос дольше, однозначно. Ведь сравнение на больше/меньше при проведение фактически бесплатное...
Или я чего-то не понимаю?

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

classic писал(а) 02. Ноября 2010 :: 13:34:

п.1 не нужен в 8.2
сразу п.2 и п.3

classic писал(а) 02. Ноября 2010 :: 13:34:


идея уводить проверку остатков в конец процедуры проведения связана с:

1. более простым запросом проверки - чем проще запрос, тем лучше ведет себя транслированный SQL запрос, а значит быстрее
2. чем быстрее запрос - тем меньше времени живет блокировка

и кстати по порядку - Артур почти правильно написал:

методика советует нечто следующее, если я правильно помню:

раньше было:
0. делаем всякую расчетную ересь - в том числе себестоимость
1. подготавливаем движения документа и проверяем остатки одним запросом
2. проводим если не было отрицательных остатков

стало:
0. делаем всякую расчетную ересь - в том числе себестоимость
1. подготавливаем движения документа запросом
2. проводим без всяких проверок
3. запросом ищем возникшие отрицательные остатки.

еще раз идея: один запрос со сложным соединением и 2 запроса без всяких JOIN'ов ведут себя совершенно по разному.

P.S. Кстати отдельно говорилось, что в сложных случаях все равно надо включать голову, помня в том числе и о новой методике.

1с утверждает что данная методика в основном для уменьшения времени блокировки итоговых таблиц.

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

Z1 писал(а) 03. Ноября 2010 :: 12:29:


вообще отдельно говорится что необходимо менять принцип проведения - в частности для исключения неверных остатков явно управлять блокировкой.

кстати - в 8.2 изменилось поведение "читающего запроса" - теперь его блокировки живут не до конца транзакции (как было раньше), а до конца выполнения запроса - если мне не изменяет память.

В 8.2 изменен принцип блокировки.
Итоги блокируются при команде "Записать" движений в регистр.
либо управляемыми блокировками.
И "новая" методика работает так:
Формируем набор движений, быстро записываем и быстро проверяем хватило ли?

в решениях 8.2 1с  отказывается от автоматических блокировок, которые ставятся при входе в обработчик проведения.
стараясь поставить как можно позже

Идея 1с чтобы "Управляемыми" блокировками пользоваться как можно реже.
Стандартная методика проведения:
1) Блокируем изменяемые данные
2) Выполняем проверку доступности данных,
3) Формируем набор движений
4) Открываем транзакцию
5) Записываем.
6) Фиксируем транзакцию и отменяем блокировку
Все это время данные заблокированы.

"Новая" методика
1) Формируем набор движений
2) Открываем транзакцию
3) Записываем - только в этот момент изменяемые данные блокируются.
4) Выполняем проверку
5) Фиксируем транзакцию и отменяем блокировку

Общее время блокировки во втором случае должно быть меньше.

"Новая" методика не всегда применима.

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

lustin писал(а) 03. Ноября 2010 :: 13:51:

опишите что это такое

Z1 писал(а) 03. Ноября 2010 :: 13:55:


режим разделения итогов включить/выключить: при одновременной записи строк регистра по одинаковым измерениям будет создано более одной строки в таблицах итогов регистра - что приводит к повышению параллельности работы.

P.S. и вот только сейчас вспомнил - что не помню в какой конкретно версии введен режим разделения итогов - оказалось еще с тестовой 8.1 http://forum.klerk.ru/showthread.php?t=112638

lustin писал(а) 03. Ноября 2010 :: 14:12:

не вижу выигрыша считать остатки надо будет дольше
v7 не допускает ошибок ( просто падает ) если каким либо образом
пытаетесь добавить (insert )  тот же самый набор в rg
здесь же из-за какой либо ошибки ( сбился индекс и.т.д)
возможно будет записать неправильные данные.
+ в v7 индекс уникальный а описанная схема это исключает и работа с итоговыми таблицами в целом замедлится

Igor-bts писал(а) 08. Ноября 2010 :: 06:27:
Писать сложнее т.к. гораздо легче попасть на взаимоблокировку.



Цитата:
Я имею ввиду что в этом случае вычисление остатков будет занимать больше времени и очень сложно оценить стоит ли это применять или нет. На мой взгляд не стоит.




Также давайте обсудим когда начинается транзакция.
Если в v8 есть аналого при записеПерепроводить транзакция должна начинаться при записи документа(речь об ms sql)

Igor-bts писал(а) 08. Ноября 2010 :: 08:20:

По-старому это как? ИМХО только новый вариант возможен.
Или ты про НаборЗаписей.Записать = ложь; ?
Пояснишь?
ЗЫ я еще только-только 8.2 начинаю щупать на самом деле.

Igor-bts писал(а) 08. Ноября 2010 :: 14:36:

Так старой методики больше нету в 8.2, разве нет?
Иначе поясни, как на 8.2 запустить старую схему

Igor-bts писал(а) 08. Ноября 2010 :: 15:08:


Каким оператором t-sql накладывается блокировка на итоговые таблицы регистров.

Еще вопрос стоит ли дискутировать с Вами по поводу #25 ?
Дело в том что v8 не знаю и что либо утверждая как то некомфортно себя ощущаю ( мои утверждения основываются на v7 , знания ms sql и общие знания по построению регистра накопления )