Нужна информация, какие именно операции производит платформа при различных операциях с метаданными. Ну то есть, в каких случаях вообще ничего не делает кроме записи md, в каких производит поиск ссылок, в каких пересчет итогов, в каких пересчет отборов и так далее. Просто некоторые операции быстрые, а некоторые оооочень долгие. И перед тем, как записывать изменения, хочется как-то прогнозировать время реструктуризации.

Существует ли некая документация, официальная или неофициальная, на эту тему?

(0) реструктуризация делается, только при изменении самих метаданных - изменения типа реквизита\добавление\удаление.. или удаление\добавление объекта метаданных.
Всё остальное не приводит к реструктуризации. Управлять этим просто - использовать turbomd.dll

А долгая реструктуризация - просто копия объекта и копирование в неё всего .. там нет альтер тэйбл

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

(2) Основное время тратится не на прямую реструктуризацию, а на косвенную. На пересчет ссылок, пересчет отборов, итогов. С ними то как быть?

(4) смотря чего меняешь. Итоги и все остальное, можно и самому пересчитать прямым запросом.
Все что не трогает метаданные, у нас было через турбомд на-ходу.

(5) Как узнать, что трогает а что не трогает?
Вот удаляю я например вид документа, таких документов в базе нет - начинается пересчет ссылок на много часов. Это как объяснить?

(6) iddocdef есть в табличке 1sjourn же..вот и пересчет

(7) Вот и нужна инфа подобного рода в виде документации или шпаргалки

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

втыкай: https://infostart.ru/1c/articles/17029/

(8) Да нафига ? :) Ну посмотри за структуру хранения ..там всего то с гулькин нос, и всё станет понятно, почему так, а не эдак.

(11) Да непонятно вот. Например, почему пересчет ссылок при удалении вида документа происходит, если в журнале нет ни одного документа удаляемого вида?

(12) там же еще 1crdoc

+ проверка поиска этого вида дока во всех метаданных

(14) Разве не логично, что если документ отсутствует в журнале и в основных таблицах DT и DH, то он отсутствует и в базе. И нет смысла искать ссылки на него во всех других метаданных. А у 1с7 какое-то параноидальное поведение, искать то чего нет. А если где-то и осталась ссылка, то она в любом случае висячая и нет смысла её искать в рамках применения изменений.

(15) ну и переписывать всю таблицу - тоже нелогичное поведение. однако оно так есть. Ибо (2).
Прими это как данность.
Бороться - только "реструктуризация руками"

(16) Я так понял, что при удалении документа, отсутствующего в базе, вся эта тряхомудия многочасовая с поиском ссылок нафиг не нужна, по факту никаких изменений в данных не происходит. И можно спокойно срубить процесс 1с, удалить файлики 1srecalc.cmd из каталогов ИБ и newstru, и начинать работать - метаданные изменились уже.

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

(17) я не люблю "рубить процессы".  поэтому предпочитал делать руками. Тем более база была довольно таки приличная - там "штатных методов" можно было и не дождаться....

(18) А можно технологию, как именно всё "делать руками"? Вы для этого какой-то инструмент писали специальный на прямых запросах? Или как?

(19) Прям так часто конфу меняете, что есть правка самой структуры метаданных ?
Ради добавления одного реквизита, можно да и руками поправить таблички. Да и нет там инструмента.Один сплошной ручной труд.

(19) не, у меня не так уж часто требовалась какая-то большая реструктуризация.
пожалуй, единственный раз возник вопрос о порядке - trad подсказал (Знатоки T-SQL, подскажите, можно ли ВСТАВИТЬ новую колонку в таблицу Ну да, какая-то искалка-удалялка в 1scrdoc была. Пересчет регистров - недавно кому-то давал, с инфостарта почему-то удалили. Да, на инфостарте была еще "замена штатного ТиИ" от Z1, если память не изменяет.

на пустой базе делается реструктуризация - имеешь мд и дд(ддс). Всё собственна. В рабочей руками добавляешь свой реквизит в таблички, подменяешь мд и словарик с пустышки. Базу пустышку используешь как образец для просмотра имени добавленного реквизита и т.п.
При необходимости, пересчет итогов, если меняешь регистр. Всё

(22) плюс можно на копии итоги пересчитывать или добавляь в справочники поля с отбороами, а потом переносить.
в общем,Ю куча вариантов, но как правило не автоматизируемых

(23) автоматизировать то можно всё, только смысл ? Метаданные не так часто меняются в части реквизитов.
А для всего остального есть turbomd

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

(15) "Разве не логично, что если документ отсутствует в журнале и в основных таблицах DT и DH, то он отсутствует и в базе."
- не логично. это как искать логику в Налоговом кодексе.
Если бы было логично - не было бы битых ссылок в регистрах, а я с этим постоянно сталкиваюсь в мелких лавочных конторах где хрензнает кто дела свертку хрен знает как и все пописяно прямыми запросами...

(26) Нууу, когда мы говорим о реструктуризации - мы подразумеваем, что база исправна. А не вытащенная с битого райд-массива или которую кривыми руками прямыми запросами обрабатывали! ) Давайте не путать теплое с мягким - реструктуризацию ИБ при изменении метаданных с ТИИ.

ну, пдразумевать-то можно что угодно. в т.ч и оптимистичный сценарий...

(19) Может это поможет http://www.script-coding.com/v77tables.html

(29) Это полезно, но во-первых там ноль информации о бухгалтерской компоненте, во-вторых там не раскрыта тема о том, что происходит при реструктуризации.

(30) по бухкомпоненте - можешь глянуть описание ПоставщикДанных, опираясь на это - поймешь устройство. Хотя если поймешь идеологию построения - и так разберешься.
ну и по реструктуризации - смотришь на вспомогательные таблицы, и с учетом (2) понимаещь, что происходит...

(30) бух компонента тоже описана вся

Там особо то ничего и нет в ней

(15) нормальное поведение. при удалении документа или справочника всегда идет поиск удаляемого объекта во всех документах и справочниках, у которых есть реквизит неопределенного типа...

(34) или без вида.

(34) Ну, во-первых, глупо искать то, чего нет, искать ссылку на объекты, которых нет в базе. А во-вторых, поиск путем последовательного перебора, а не запросом на выборку данных - тоже так себе решение.

(36) "понять и простить"©
Ну что ты хочешь от того, что разрабатывалось в конце 90-х, для файловой БД, и не развивалось с 2000-го, и воообще не трогалось с 2006 (7.70.027) ?