Как лучше хранить дополнительные табличные данные документа: в новой табличной части, регистре сведений или отдельном документе?

При доработке прикладных решений разработчики часто сталкиваются с задачей расширения существующего функционала. Предположим, для типового или самописного документа требуется добавить дополнительную таблицу (например, расчет скидок, согласование цен или список сопутствующих кондиций), которая заполняется далеко не всегда и используется лишь частью пользователей. Возникает вопрос: как это повлияет на объем базы данных и какой архитектурный подход выбрать — добавить новую табличную часть, создать независимый регистр сведений или вынести процесс в отдельный документ?

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

Физическая структура хранения данных в СУБД: табличная часть против регистра сведений

Главное опасение разработчиков при мысли о добавлении табличной части в документ с миллионами существующих записей заключается в том, что база катастрофически вырастет из-за появления «пустых таблиц» в каждом историческом документе. Выясним причину этого заблуждения и посмотрим, как устроены таблицы на уровне базы данных.

В платформе 1С табличные части объектов не хранятся внутри основной таблицы документа. Каждая табличная часть представляет собой отдельную физическую таблицу СУБД со следующей структурой полей:

1. Ссылка на документ-владелец (поле связи с шапкой документа).
2. Поле НомерСтроки (индекс строки в табличной части).
3. Колонки с данными, соответствующие добавленным реквизитам табличной части.

Сравним структуру таблицы табличной части со структурой регистра сведений. В регистре сведений для решения аналогичной задачи создается таблица со следующими полями:

1. Измерение ДокументСсылка (ссылка на целевой документ).
2. Измерение НомерСтроки (порядковый номер записи).
3. Ресурсы и реквизиты регистра, повторяющие состав колонок.

Таким образом, на уровне СУБД табличная часть документа и регистр сведений практически идентичны по структуре и занимаемому объему. Если документ не содержит строк в табличной части, в соответствующую физическую таблицу базы данных не добавляется ни одной записи. Пустые строки на диске не хранятся, а создание новой табличной части лишь добавляет пустую таблицу в структуру метаданных СУБД без изменения объема уже существующих документов.

Сравнение архитектурных вариантов реализации

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

Вариант 1. Добавление новой табличной части в документ

Этот вариант является самым естественным с точки зрения объектной парадигмы 1С. Если данные логически принадлежат конкретному документу и составляют его неотъемлемую часть, платформа берет управление целостностью на себя.

Преимущества решения:

1. Целостность данных «из коробки»: при копировании, пометке на удаление или физическом удалении документа платформа автоматически удаляет и копирует строки его табличных частей.
2. Простота разработки: не нужно писать вспомогательный программный код для синхронизации, чтения и ручной записи движений.
3. Штатные механизмы форм: привязка элементов формы к реквизитам объекта работает прозрачно и производительно.

Ограничения и подводные камни:

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

Вариант 2. Хранение данных в регистре сведений

Использование независимого регистра сведений оправдано, когда процесс работы с дополнительными данными должен быть отвязан от жизненного цикла проведения самого документа.

Преимущества решения:

1. Быстрое обновление: добавление нового регистра сведений создает новую таблицу в СУБД мгновенно, не затрагивая основные таблицы существующих документов.
2. Отсутствие конфликтов блокировок: запись в регистр сведений не меняет ВерсиюДанных самого документа и не блокирует одновременную работу других пользователей с документом.
3. Редактирование без перепроведения: менеджеры могут вносить и сохранять сведения о согласовании на любом этапе, даже если документ уже проведен и закрыт для редактирования в прошлых периодах.
4. Гибкость разграничения прав: права на чтение и запись регистра можно легко назначить отдельной специализированной роли без изменения типовых прав на документ.

Особенности реализации:

1. Контроль ссылочной целостности: для предотвращения появления «зависших» записей при удалении документа измерению регистра, содержащему ссылку на документ, обязательно необходимо установить свойство «Ведущее». В этом случае при физическом удалении документа платформа автоматически очистит связанные записи регистра.
2. Программное управление записью: чтение данных и их сохранение из формы обработки придется реализовывать вручную через объект НаборЗаписей.

Посмотрим на пример программной записи данных в регистр сведений:

НаборЗаписей = РегистрыСведений.СогласованиеКондицийТоваров.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ДокументСсылка.Установить(СсылкаНаДокумент);

// Заполняем набор из переданной таблицы значений или формы
Для Каждого Стр Из ТаблицаДанных Цикл
    НоваяЗапись = НаборЗаписей.Добавить();
    НоваяЗапись.ДокументСсылка = СсылкаНаДокумент;
    НоваяЗапись.НомерСтроки    = Стр.НомерСтроки;
    НоваяЗапись.Номенклатура   = Стр.Номенклатура;
    НоваяЗапись.Цена           = Стр.Цена;
    НоваяЗапись.Сумма          = Стр.Сумма;
КонецЦикла;

НаборЗаписей.Записать(Истина);

Вариант 3. Вынесение в отдельный документ согласования

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

Преимущества решения:

1. Полноценный жизненный цикл: у процесса согласования появляются собственный автор, дата, время, ответственные лица и статусы (согласовано, отклонено).
2. История и версионирование: при необходимости повторного согласования можно создать второй документ, сохранив историю предыдущих решений.
3. Структура подчиненности: связь между документами видна стандартным механизмом платформы, что упрощает аудит и анализ цепочки документов.

Итоги и рекомендации

Проанализируем критерии выбора между предложенными вариантами:

1. Если данные нужны только как техническая часть документа, заполняются в процессе его стандартного ввода и не требуют параллельного редактирования после проведения — выбираем табличную часть документа. Опасаться за размер базы не нужно: пустые строки дисковое пространство не расходуют.
2. Если данные должны вноситься в уже проведенный документ узким кругом лиц без блокировки работы остальных пользователей и без риска изменения движений документа — используем регистр сведений с признаком «Ведущее» у измерения ссылки.
3. Если согласование цен — это самостоятельный регламентный этап бизнес-процесса со своими статусами и историей — создаем отдельный подчиненный документ.