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

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

Крик души. Просто база большая и это достает.
Если у кого есть соображения, зачем 1с так делает, высказывайтесь.

* версия 8.2

индексы, итоги

(2) та вот почему и в регистрах, которые и так были в движениях документа? Там ни итоги ни индексы по идее не меняются.

Затем же зачем записывать документ и все табличные части со всеми строками при изменении одного реквизита видимо.

+(4) Не, ну а чо, делаем один признак "изменены" движения, и при его установке всегда выполняем один и тот же код. Меньше кода, меньше багов, меньше переписывать.

(4) Это не так.

(5) ОбменДанными.Загрузка = Истина?

(4) А откуда система должна знать, что ты там поменял? У нее есть стандартный UPDATE TABLE, а что ты там поменял - дело десятое.

(8) Нет никакого update, есть delete и insert.

(9) Ты не поверишь.

(4) некорректное сравнение. при изменениях в реквизитах должна быть реструктуризация всех документов этого вида.

А на кой ляд реструктуризируются регистры, в которых 100% ничего с точки зрения содержимого не меняется??

(10) Вот специально полез в профайлер, поменял реквизит в 1 строке 1 табличной части, в итоге Delete из всех табличных частей, и INSERT в те, которые содержат строки. Так что да, не поверю.

(10) в принципе, есть или нет, с точки зрения здравого смысла не важно. Скорость от этого зависит, конечно. А по сути - на двух или трех ногах 1с бегает- пользователь не знает и хочет знать.

(11) Это было не про конфигуратор.

(12) ТЧ - да, основная таблица через update

(14) ну и как ты свяжешь теперь это с моим вопросом?

(16) Да очень просто. В том и другом случае можно было заморочиться и отдельно обрабатывать каждый случай, но не сочли нужным.

(12) Перепроведи документ с изменением тч и посмотри на движения и остатки РН.

(17) а про большие базы подумали. а про то, что в списке уже бывших в движениях мог быть Хозрасчетный? Неужели так низко.. <запипикал>.

(0) >а вот вам и нет,- идет во всех.
Как определил?

(1) А точнее?

(18) Лень. Верь, что там "оптимизировали", анализируя через временные таблицы что в движениях поменялось. Я не об этом хотел дискутировать, а о том, что объект записывается целиком и отрабатывают все события на объект в целом.
Можно было усложнить, но тогда тупым одинэсникам пришлось бы изрядно поумнеть и скорость разработки неизбежно упала бы.
Собственно в Аксапте можно работать непосредственно с таблицами, если какие-то имеющиеся классы не предоставляют нужной функциональности на уровне самого объекта. Отсюда и человеко/месяцы на то, что в 1С можно сделать за пару часов.

(20) глазами чтоли не видно что пошла реструктирузация такого большого, как Хозрасчетный. да и по времени это полдня пиления. Другой вопрос, что за этой "реструктуризацией" стоит, что я и спрашиваю.

(19) Переходи на 8.3, тем более с большими-то базами.

(23) уже на подходе. Что, там такого нет?

(22) Посмотри в профайлере, потом нам расскажешь. Ставлю на то, что создается копия таблицы, в нее заливаются данные, строятся индексы, пересчитываются итоги.

(25) Вы таки выиграли свой приз.