Купил, наконец-то 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) Фиксируем транзакцию и отменяем блокировку

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

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