В процессе доработки конфигураций 1С разработчики нередко сталкиваются с необходимостью расширить аналитику существующего регистра сведений. Закономерно возникает вопрос: не приведет ли добавление нового измерения к стиранию или повреждению уже накопленных записей? Разберем подробно, как платформа 1С обрабатывает реструктуризацию регистра сведений, что происходит с ключом уникальности и на какие технические нюансы следует обратить внимание перед обновлением базы данных.
Проанализируем базовый принцип хранения информации в регистрах сведений 1С. Ключ уникальности записи в независимом регистре сведений формируется совокупностью всех его измерений (а для периодических регистров — также и периодом). Если в регистре уже существуют записи, их уникальность гарантирована текущим составом измерений.
При добавлении нового измерения ключ уникальности расширяется. Добавление дополнительного поля в ключ не может сделать ранее различные комбинации измерений одинаковыми. Поэтому платформа 1С при обновлении конфигурации базы данных сохраняет все существующие строки в полном объеме. Риск потери данных или дублирования возникает только при удалении измерения, когда две ранее различные записи схлопываются в одинаковые ключи и платформа блокирует реструктуризацию из-за нарушения уникальности.
Выясним, какие значения получат существующие записи в добавленном поле. Платформа 1С автоматически подставляет значение по умолчанию, соответствующее выбранному типу данных:
Справочники.Номенклатура.ПустаяСсылка()).0."".Ложь.'00010101000000'.Таким образом, существующие записи остаются валидными, но требуют анализа бизнес-логики: допустимо ли для вашей системы хранение пустых значений в новом разрезе аналитики.
Разберем свойства измерения в дереве метаданных, некорректная настройка которых может нарушить работу системы после добавления:
1. Свойство «Запрет незаполненных значений»
Если при создании нового измерения включить данный флаг, то любая попытка последующей записи наборов данных без явного заполнения этого поля приведет к исключению платформы. Рекомендуется сначала добавить поле без этой проверки, заполнить данные регламентной обработкой и только затем при необходимости активировать запрет.
2. Свойство «Ведущее»
Если новое измерение имеет ссылочный тип и вы устанавливаете флаг Ведущее, начинает действовать механизм каскадного удаления: физическое удаление объекта по ссылке приведет к автоматическому удалению всех строк регистра, в которых эта ссылка была указана.
Особое внимание обратим на периодические регистры сведений. Таблицы СрезПоследних и СрезПервых рассчитываются в разрезе комбинации всех измерений. Рассмотрим, как изменится логика существующих запросов:
До добавления измерения запрос среза возвращал ровно одну актуальную запись для прежнего набора аналитики. Как только в регистре появятся записи с заполненным новым измерением, срез последних начнет возвращать актуальную строку для каждого уникального значения нового измерения. Если отчеты или проведение документов ожидают получить строго одну запись, их логика может дать непредвиденный результат. Проанализируйте все обращения к виртуальным таблицам регистра перед внесением изменений.
Если регистр сведений подчинен регистратору, данные в него записываются исключительно документами при их проведении. Добавление измерения в метаданные регистра не заполнит его в движениях ранее проведенных документов. Для обновления архивных записей без перепроведения самих документов-регистраторов используем программную перезапись наборов записей с установкой признака обмена данными.
Посмотрим на пример обработки таких записей:
Набор = РегистрыСведений.ЦеныНоменклатуры.СоздатьНаборЗаписей();
Набор.Отбор.Регистратор.Установить(ДокументСсылка);
Набор.Прочитать();
Для Каждого Запись Из Набор Цикл
// Заполняем новое измерение нужным значением
Запись.НовоеИзмерение = ЗначениеНовогоИзмерения;
КонецЦикла;
Набор.ОбменДанными.Загрузка = Истина;
Набор.Записать();
Свойство ОбменДанными.Загрузка = Истина позволяет обойти избыточные проверки и не вызывает перепроведение самого документа-регистратора.
Все измерения регистра сведений входят в его первичный кластерный индекс на уровне базы данных СУБД (PostgreSQL, MS SQL Server и др.). Добавление нового поля в ключ таблицы инициирует полную физическую перестройку таблицы и её индексов.
На больших базах с десятками миллионов строк операция обновления конфигурации базы данных может вызвать монопольные блокировки и занять значительное время. Для исключения сбоев разберем регламент выполнения таких операций: