Часто в практике разработки на платформе 1С:Предприятие возникает классическая задача: к существующему документу (например, «Заказ покупателя») нужно «присоединить» новую таблицу. Это может быть список дополнительных документов, логов, статусов или контактной информации со строковыми, числовыми и ссылочными реквизитами. Структура таблицы заранее известна. Возникает вопрос: как архитектурно правильно разместить эти данные в системе?
Проанализируем ситуацию и рассмотрим несколько основных подходов, выясним причину распространенных заблуждений и разберем по шагам оптимальные решения.
Самый простой и очевидный подход — добавить новую табличную часть (ТЧ) непосредственно в сам документ. В эту табличную часть добавляются нужные реквизиты, после чего она выводится на форму, и для нее прописываются необходимые обработчики событий.
Преимущества:
Недостатки и мифы:
Многие разработчики боятся, что добавление табличной части с большим количеством строк приведет к «раздутию базы» и падению производительности. Разберем этот миф. На физическом уровне СУБД (например, MS SQL Server) любая табличная часть документа — это отдельная физическая таблица, связанная с основной таблицей документа внешним ключом. Регистр сведений — это точно такая же таблица. По объему на жестком диске разницы практически не будет.
Однако разница есть в потреблении оперативной памяти сервером 1С. При программном обращении к объекту (получение через ДокументОбъект) платформа считывает в оперативную память все его табличные части. Если строк тысячи, это действительно замедлит работу с объектом при его проведении или записи.
Главное ограничение: Данные в табличной части нельзя изменять без перезаписи (и, как правило, перепроведения) всего документа. Если бизнес-логика требует внесения дополнительных данных по старым, уже проведенным и закрытым периодом документам, табличная часть нам не подойдет.
Если дополнительные данные необходимо обновлять уже после проведения документа, и перепроводить его нельзя, лучшим выбором станет создание отдельного независимого регистра сведений (РС).
В таком регистре создается ведущее измерение Документ (например, с типом ДокументСсылка.ЗаказПокупателя), а остальные нужные поля добавляются как ресурсы, реквизиты или дополнительные измерения.
Как вывести это на форму документа для редактирования «в списке»?
Если мы просто выведем динамический список регистра с отбором по документу, записи придется редактировать в отдельном открывающемся окне (форме записи), что часто неудобно пользователям. Рассмотрим подробнее два способа организации редактирования прямо в форме документа:
РегистрСведенийНаборЗаписей.ИмяВашегоРегистра. Перетаскиваем этот реквизит на форму документа. При открытии формы нужно программно установить отбор набора записей по текущему документу. Это позволит пользователю редактировать данные в таблице на форме аналогично табличной части.
ТаблицаЗначений. При открытии формы данные из регистра читаются и переносятся в ТЗ. При записи (или по отдельной кнопке «Сохранить доп. данные») данные из ТЗ пишутся обратно в регистр. Для удобной конвертации коллекций разработчику помогут методы РеквизитФормыВЗначение и ЗначениеВРеквизитФормы. Этот метод требует больше программной возни, но позволяет гибко управлять итогами, оформлением и сложными проверками перед записью.
Подводные камни регистра сведений: транзакции и блокировки
При использовании независимого регистра сведений платформа не блокирует автоматически сам документ и другие записи регистра от параллельного изменения другими пользователями. Два человека могут открыть одну и ту же форму и начать вносить данные. Чтобы избежать коллизий, вам придется вручную программировать логику пессимистичных или оптимистичных блокировок при редактировании таких данных.
В современных типовых конфигурациях 1С присутствует Библиотека стандартных подсистем (БСП). В ней уже реализован механизм подсистемы «Дополнительные реквизиты и сведения».
Прежде чем разрабатывать свои таблицы, посмотрите на возможности БСП. Существуют паттерны, позволяющие администратору в режиме «Предприятие» конструировать целые подобия дополнительных табличных частей, не прибегая к разработке в Конфигураторе.
Если таблица носит исключительно справочный или технический характер (например, логи интеграции, история изменения статусов, служебные комментарии) и по этим колонкам не планируется строить запросы или отчеты, данные можно хранить в виде массива JSON.
Создается один реквизит с типом «Строка» (неограниченной длины) или ХранилищеЗначения. При открытии формы эта строка парсится и выводится в Таблицу Значений. При закрытии сериализуется обратно в JSON. Это самое «легковесное» решение, которое вообще не требует добавления новых физических таблиц в метаданные.
Времена, когда для добавления реквизита или табличной части нужно было «снимать конфигурацию с замочка» (с полной поддержки), давно прошли. Сегодня для изменения структуры данных, добавления новых объектов (Регистров Сведений) и корректировки управляемых форм следует использовать Расширения конфигурации. Это позволит вам гибко решать задачи бизнеса, оставляя основную конфигурацию типовой для легкого обновления.
Исходите из бизнес-логики: