← На главную

В процессе разработки и сопровождения крупных систем на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда добавление или удаление обычного справочника инициирует длительную процедуру реструктуризации огромных регистров (например, РегистрСведений.ВерсииОбъектов). На первый взгляд это кажется нелогичным: структура хранения ссылки в базе данных SQL для составных типов вроде бы статична. Разберем детально, почему это происходит, как платформа взаимодействует с СУБД и что меняется во внутренних механизмах 1С.

Физическое представление ссылочных данных в SQL

Для начала проанализируем, как 1С хранит ссылки в таблицах СУБД. Если реквизит имеет простой ссылочный тип (например, только СправочникСсылка.Номенклатура), в таблице создается одно поле _RRRef (UUID объекта). Однако, как только мы включаем составной тип данных или используем общие типы СправочникСсылка, ДокументСсылка или ЛюбаяСсылка, структура поля в SQL меняется. Рассмотрим три ключевых поля, которые образуют составную ссылку:

1. _TYPE — идентификатор категории типа (например, числовой код, определяющий, что это ссылка на справочник, документ или примитивный тип).
2. _RTRef (Record Type Reference) — внутренний идентификатор таблицы метаданных. Каждому справочнику или документу в системе присвоен свой уникальный числовой код таблицы.
3. _RRRef (Record Reference) — непосредственно 16-байтный уникальный идентификатор конкретной записи в той таблице, на которую указывает _RTRef.

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

Старый механизм реструктуризации (Version 1)

Рассмотрим основной механизм, который использовался в платформе десятилетиями. Его главная особенность заключается в том, что он ориентируется на описание метаданных, а не на фактическую структуру таблиц в SQL. Проанализируем логику его работы:

Когда вы добавляете новый справочник в конфигурацию, он автоматически становится частью коллекции СправочникСсылка. Поскольку тип данных в регистре определен как составной (включающий все справочники), платформа видит, что описание типа изменилось. Для старого механизма пометка Attribute type CHANGED является безусловным триггером к действию.

Процесс происходит по следующему алгоритму:

1. Создается временная таблица в СУБД с префиксом _v8_tmp.
2. Платформа копирует все данные из старой таблицы в новую.
3. Удаляется старая таблица.
4. Временная таблица переименовывается в основную.
5. Заново создаются все индексы.

Именно поэтому на регистре ВерсииОбъектов, где могут быть миллионы записей, этот процесс занимает часы. Платформа не проверяет, изменился ли физический размер колонок в SQL — ей достаточно факта изменения состава типов в метаданных.

Внутренние идентификаторы типов и целостность

Разберем подробнее роль поля _RTRef. Платформа 1С ведет внутренний реестр (DBSchema), где сопоставляет числовые коды с именами таблиц. При добавлении нового объекта метаданных этот реестр расширяется. Реструктуризация в данном случае выступает способом "перерегистрации" поля в схеме базы данных. Платформа должна гарантировать, что механизмы контроля ссылочной целостности и объектная модель (например, метод ПолучитьОбъект()) будут корректно интерпретировать новые значения _RTRef, которые могут появиться в этой колонке.

Ситуация осложняется при удалении справочника. Рассмотрим, почему здесь реструктуризация неизбежна. Даже если в регистре нет ни одной записи, ссылающейся на удаляемый справочник, 1С обязана это проверить. На уровне СУБД выполняется поиск и очистка "битых" ссылок. Старый механизм делает это радикально — через полную перезапись таблицы, фильтруя записи в процессе копирования.

Оптимизированная реструктуризация (Version 2)

Начиная с версии 8.3.11, разработчики платформы реализовали оптимизированный механизм. Проанализируем ситуацию: как он ведет себя в подобных случаях? В отличие от старого подхода, новый механизм выполняет сравнительный анализ физических схем.

Если поле имеет тип ЛюбаяСсылка, и вы добавили справочник, оптимизированный механизм понимает, что структура _TYPE, _RTRef и _RRRef в SQL не изменилась. В идеальных условиях он должен выполнить только ALTER TABLE или вообще ничего не менять на уровне базы данных.

Однако на практике мы часто видим, что реструктуризация всё равно запускается. Проанализируем возможные причины:

• Наличие индексов: Если поле входит в состав индекса, платформа может инициировать перестроение этого индекса для корректной работы оптимизатора запросов СУБД с учетом расширения диапазона значений типов.
• Сложные составные типы: Если тип реквизита не "все справочники", а ограниченный набор (например, Справочник.Склады и Справочник.Контрагенты), и вы добавили туда третий справочник, 1С может изменить внутренние правила валидации данных.

Кейс с регистром "ВерсииОбъектов"

Выясним причину, по которой именно этот регистр становится "бутылочным горлышком". В типовых конфигурациях (на базе БСП) измерение Объект в этом регистре имеет тип ЛюбаяСсылка.

Рассмотрим ситуацию: мы удаляем неиспользуемый справочник БонусыПрошлыхЛет. Платформа анализирует все таблицы, где есть ЛюбаяСсылка. Регистр ВерсииОбъектов попадает в этот список. Чтобы гарантировать, что в базе не останется записей версий для уже несуществующего справочника, 1С запускает процесс обработки этого регистра. Если включен старый механизм реструктуризации — вы получаете полную переливку таблицы на несколько терабайт из-за одного маленького удаленного справочника.

Как минимизировать последствия реструктуризации?

Проанализируем шаги, которые помогут ускорить процесс обновления конфигурации:

1. Использование оптимизированного режима: Убедитесь, что в параметрах обновления или в настройках сервера 1С включена оптимизированная реструктуризация. Однако помните о рисках (как упоминалось в обсуждении, этот механизм иногда может работать нестабильно на очень специфических структурах).
2. Анализ состава типов: Старайтесь не использовать ЛюбаяСсылка или СправочникСсылка в огромных таблицах без крайней необходимости. Если вы точно знаете, что в регистре будут храниться только ссылки на 5 конкретных справочников — укажите их явно. Это не избавит от реструктуризации при изменении этих 5 типов, но избавит от нее при добавлении 100 других справочников в систему.
3. Очистка данных перед удалением: Перед тем как удалить объект метаданных из конфигурации, программно очистите все записи в больших регистрах, которые на него ссылаются. Это может не отменить реструктуризацию, но уменьшит объем работы платформы по проверке ссылочной целостности.
4. Прямая работа с SQL (только для экспертов): В исключительных случаях, когда штатное обновление невозможно из-за временных ограничений, специалисты прибегают к ручной корректировке таблиц метаданных DBSchema, но это нарушает условия поддержки и крайне опасно.

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