Честно говоря ниасилел где будет огромный выигрыш
Вот проводить одну строку вместо 200 - дело другое...
Можно пояснить для тупых когда взлетит поподробнее?

Про что статья то?

all ну неужели вы не видете фишку ?
А если сказать так - это будет лучше чем гибкие блокировки

Nick писал(а) 13. Ноября 2008 :: 10:04:

почему ??? ТЕстовая база работает уже с понедельника.
Сейчас думаю как все это переносить в рабочую базу.
Также думаю над оптимизацией того что есть. Но по некоторым вещам не хватает знаний.
Ближайшая цель убрать курсоры в хп ra...

база сейчас тестовая копия реальной.
Все основные действия пользователей работают правильно.
Чтобы перевести на реальную базу Цитата:

Ключевое слово : другой Алгоритм проведения.
лучше чем тот который есть сейчас, а реализовать алгоритм можно так как есть точки доступа в виде xp.

сейчас выложу в ветку

Пролог

Все началось с того, что перевалив какой то предел 1с стал «Тормозить».
Возникают пиковые ситуации все процессы становяться в очередь на проведение и все :  1с "умирает". Очередь по блокировкам wait доходит до 5-10 и все alles.
Отдельно работающие пользователи все ок.
Стал думать о гибких блокировках. Прочитал о существующих решениях.
Полез внутрь хп. Сначала нашел несоответствие по переполнению регистра 99999
Ветка на 1с++ (  http://www.1cpp.ru/forum/YaBB.pl?num=1225518509 )
После этого почитал умные книжки по sql и написал свою реализацию гибких блокировок.
Стал рисовать картинки на бумаге. Получалась довольно невзрачная картина либо
возможны взаимные блокировки строк таблиц базы,
либо стоимость блокировок становилась огромной и решение становилось бы
сопоставимым с тем какое есть сейчас.
После этого стал «копать» еще глубже и разбираться как оно все работает.
В частности как работает 1с с регистрами.

Чтобы понять недостатки вышеописанного алгоритма  рассмотрим несколько примеров :

Пример №1.
Пусть есть проведенный документ Приходная Накладная от 10.01.2008 ( т.а стоит на 31.12.2008) Скажем 200 строк с разными товарами.
В этом документе изменяем примечание и сохраняем и перепроводим документ
Что при этом будет происходить
Начинает работать ОчиститьДвижения()
1.Для каждого движения ( каждой строки т.к. у нас на одну строку одно движение)
Для всеx периодов уменьшаем значение таблицы  RG
2. Для данного документа очищается все RA ( как вызывается метод ) не знаю.
Для каждой строки в МодулеПроведения выполняется ВыполнитьПриход
при этом добавляется строка в таблицу ra
и для всех периодов увеличиваем значение таблицы RG

Проделана огромная работа, а результат остался прежний.
(Для таблицы RG имеем изменено строк = 12*200*2  = 4800 update)
В идеале не надо вообще ничего делать в RG


Пример №2
Пусть есть непроведенная Приходная накладная от 12.01.2008 и в ней 10 одинаковых строк
Тов1,Склад1,15 (15 колво)
Что происходит при Записи и проведении этого документа.
Начинает работать ОчиститьДвижения()т.к. движений нет ничего не очищием.
Для каждой строки в МодулеПроведения выполняется ВыполнитьПриход
при этом добавляется строка в таблицу ra
и для всех периодов( от 01.01.2008 до 01.12.2008 ) увеличиваем значение таблицы RG на 15.

В результате имеем для таблицы RG выполнилось для каждого периода
10 одинаковых операций
увеличиваем значение таблицы RG на 15.
(всего операций по изменению 12 * 10 = 120 изменений )
В идеале хотелось иметь бы одну операцию для каждого периода
увеличиваем значение таблицы RG на 150  ( т.е. всего 12 операций)

Пример №3
берем проведенный документ из примера 2 и просто делаем отмену проведения

Начинает работать ОчиститьДвижения()
1.Для каждого движения ( у нас 10 одинаковых движений)
Для всеx периодов( у нас их 12 )
уменьшаем значение таблицы  RG на 15
(всего операций по изменению 12 * 10 = 120 изменений )

В идеале хотелось бы одну операцию для каждого периода
уменьшить значение таблицы RG на 150  ( т.е. всего 12 операций)


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