Мы сталкиваемся с распространенной задачей в разработке на платформе 1С: необходимо хранить и обрабатывать данные, структура которых не является строго фиксированной. Часто это проявляется в требовании добавлять или удалять "ресурсы" (фактически, дополнительные поля или атрибуты) для различных объектов системы, причем их количество и состав могут отличаться для каждого экземпляра основного объекта. Например, для одного "Измерения 1" могут быть Ресурс 1, Ресурс 2, Ресурс 3, а для "Измерения 2" — Ресурс 1, Ресурс 2, Ресурс 3, Ресурс 4, Ресурс 5. Как нам реализовать такую гибкую структуру данных, обеспечивая при этом удобство работы пользователя и возможность формирования отчетов?
Рассмотрим несколько основных подходов, которые предлагает платформа 1С для решения этой задачи.
Этот подход является стандартным и наиболее гибким для решения задачи с нефиксированным набором атрибутов. Он основан на использовании двух ключевых объектов платформы: ПланВидовХарактеристик и РегистрСведений. Мы будем использовать этот механизм для хранения произвольных свойств (ресурсов) для наших "измерений".
Давайте разберем его по шагам.
Создание Плана видов характеристик (ПВХ):
Начнем с создания ПланаВидовХарактеристик, например, назовем его ВидыДополнительныхРеквизитов. Этот объект будет хранить определения наших "ресурсов". Каждый элемент этого справочника будет представлять собой один из возможных дополнительных реквизитов, который пользователь сможет добавить. Для каждого такого реквизита мы указываем его наименование и тип значения. Тип значения может быть любым: Строка, Число, Дата, Булево, ссылка на другой справочник и т.д. Если наши ресурсы могут иметь разные типы, мы можем использовать составной тип для реквизита "ТипЗначения" или даже тип Характеристика, который позволяет хранить ссылки на элементы этого же ПВХ (это более продвинутый сценарий).
Обычно в ПВХ мы создаем один или несколько предопределенных элементов, которые будут служить для классификации наших характеристик (например, "Измерения" и "Ресурсы").
Создание Регистр сведений для хранения значений:
Далее мы создаем РегистрСведений, например, ЗначенияДополнительныхРеквизитов. Этот регистр будет хранить фактические значения наших динамических ресурсов.
Структура регистра будет следующей:
Измерение: Объект (тип - Характеристика, ссылающийся на наш основной справочник, который является "Измерением" в терминологии заказчика). Если Измерение однотипное, то это может быть просто ссылка на соответствующий справочник, например, СсылкаНаИзмерение (тип: СправочникСсылка.МойСправочникИзмерений).
Измерение: Свойство (тип - ПланВидовХарактеристикСсылка.ВидыДополнительныхРеквизитов). Это измерение будет хранить ссылку на элемент нашего ПВХ, который определяет, какой именно ресурс мы храним (например, "Ресурс 1", "Ресурс 2" и т.д.).
Ресурс: Значение (тип - Характеристика, ссылающийся на наш ПВХ.ВидыДополнительныхРеквизитов). Этот ресурс будет хранить фактическое значение нашего дополнительного реквизита. Использование типа Характеристика здесь критически важно, так как оно позволяет хранить значения разных типов (числа, строки, даты, ссылки) в одном ресурсе регистра, платформа автоматически "разруливает" это на уровне базы данных.
Пример структуры регистра:
РегистрСведений.ЗначенияДополнительныхРеквизитов
Измерения:
Объект (Тип: СправочникСсылка.МоиИзмерения)
Свойство (Тип: ПланВидовХарактеристикСсылка.ВидыДополнительныхРеквизитов)
Ресурсы:
Значение (Тип: Характеристика.ВидыДополнительныхРеквизитов)
Таким образом, для каждого элемента справочника "МоиИзмерения" (например, "Измерение 1") и для каждого его дополнительного ресурса (например, "Ресурс 1") будет отдельная запись в РегистреСведений.ЗначенияДополнительныхРеквизитов, связывающая объект, вид свойства и его значение.
Реализация в пользовательском интерфейсе:
Для добавления и удаления ресурсов мы можем создать на форме элемента справочника "МоиИзмерения" табличную часть, которая будет отображать записи из нашего регистра. Пользователь сможет добавлять новые строки в эту табличную часть, выбирать из ПВХ нужный вид ресурса и вводить его значение. Важно настроить форму так, чтобы поле значения автоматически меняло свой тип в зависимости от выбранного вида ресурса.
Например, при выборе ВидРеквизита с типом "Число", поле ЗначениеРеквизита на форме должно стать полем ввода числа.
Отчетность:
Основное преимущество этого подхода в том, что платформа 1С предоставляет мощные средства для работы с такими "характеристиками" в отчетах, особенно через СистемуКомпоновкиДанных (СКД). Мы можем легко выводить эти дополнительные реквизиты в отчетах как отдельные колонки. Для этого нам потребуется в запросе к регистру сведений развернуть характеристики. Это делается путем соединения нашего основного запроса с регистром характеристик и использования специальной функции или обхода записей. В СКД это часто можно настроить типовыми средствами, используя набор данных "Объект с характеристиками" или вручную в конструкторе запросов СКД.
Пример запроса для получения значений характеристик:
ВЫБРАТЬ
МоиИзмерения.Ссылка,
ЗначенияДополнительныхРеквизитов.Свойство,
ЗначенияДополнительныхРеквизитов.Значение
ИЗ
Справочник.МоиИзмерения КАК МоиИзмерения
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЗначенияДополнительныхРеквизитов КАК ЗначенияДополнительныхРеквизитов
ПО МоиИзмерения.Ссылка = ЗначенияДополнительныхРеквизитов.Объект
Этот запрос извлекает все свойства для каждого измерения. Для вывода каждого свойства в отдельной колонке в отчете СКД, вам нужно будет использовать конструктор запросов или вручную задать виртуальную таблицу "Характеристики" в СКД.
Преимущества данного подхода:
Гибкость: Пользователи могут самостоятельно, в режиме 1С:Предприятие, определять новые ресурсы без необходимости изменения конфигурации и привлечения разработчика.
Стандартность: Это типовой механизм платформы, хорошо документированный и поддерживаемый.
Масштабируемость: Подходит для большого количества различных объектов и характеристик.
Удобство отчетов: СКД предоставляет мощные возможности для построения отчетов по таким данным.
Недостатки:
Несколько более сложная структура запросов (особенно при разворачивании характеристик в колонки).
Может потребоваться разработка дополнительных форм и обработок для удобного управления характеристиками.
Если количество "измерений" (основных объектов, для которых нужны ресурсы) невелико, или если ресурсы всегда тесно связаны с конкретным "измерением" и не требуют глобального переиспользования как характеристики, можно рассмотреть вариант использования ТабличнойЧасти (ТЧ) самого справочника, который хранит наши "измерения".
Разберем, как это можно реализовать.
Структура справочника:
Создаем справочник, который будет хранить наши "измерения", например, Справочник.МоиИзмерения. В нем создаем табличную часть, например, РесурсыИзмерения.
Эта табличная часть будет иметь следующую структуру:
Реквизит ТЧ: ВидРесурса (тип - Строка или СправочникСсылка.ВидыРесурсов). Если виды ресурсов могут быть предопределены или выбираться из списка, лучше создать отдельный вспомогательный справочник Справочник.ВидыРесурсов и ссылаться на него. Если же пользователь вводит наименование ресурса "от руки", то тип будет Строка.
Реквизит ТЧ: ЗначениеРесурса (тип - Характеристика). Аналогично подходу с регистром сведений, использование типа Характеристика здесь позволяет хранить значения различных типов (числа, строки, даты и т.п.) в одной колонке табличной части.
Пример структуры:
Справочник.МоиИзмерения
Реквизиты:
... (стандартные реквизиты измерения)
ТабличныеЧасти:
РесурсыИзмерения
Реквизиты:
ВидРесурса (Тип: Строка или СправочникСсылка.ВидыРесурсов)
ЗначениеРесурса (Тип: Характеристика.ВидыДополнительныхРеквизитов - если используем ПВХ для видов, или просто "Характеристика" если ПВХ для этого справочника)
В этом случае, все ресурсы для конкретного "измерения" будут храниться непосредственно в табличной части этого элемента справочника.
Реализация в пользовательском интерфейсе:
На форме элемента справочника МоиИзмерения мы размещаем табличную часть РесурсыИзмерения. Пользователь сможет добавлять новые строки в эту табличную часть, заполняя ВидРесурса и ЗначениеРесурса. Для поля ЗначениеРесурса также можно настроить динамическое изменение типа в зависимости от выбранного ВидаРесурса, если мы используем вспомогательный справочник для видов ресурсов, или ПВХ.
Заказчик также упомянул возможность представления в виде дерева. Это можно реализовать, если добавить в табличную часть реквизит Родитель (ссылка на текущую ТЧ) и настроить динамический список на форме элемента справочника с соответствующим видом дерева.
Отчетность:
Для построения отчетов по данным из табличной части справочника мы можем использовать запросы к табличной части. В запросах СКД табличная часть доступна как виртуальная таблица Справочник.МоиИзмерения.РесурсыИзмерения.
Пример запроса:
ВЫБРАТЬ
МоиИзмерения.Ссылка КАК Измерение,
МоиИзмеренияРесурсыИзмерения.ВидРесурса,
МоиИзмеренияРесурсыИзмерения.ЗначениеРесурса
ИЗ
Справочник.МоиИзмерения.РесурсыИзмерения КАК МоиИзмеренияРесурсыИзмерения
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.МоиИзмерения КАК МоиИзмерения
ПО МоиИзмеренияРесурсыИзмерения.Ссылка = МоиИзмерения.Ссылка
Для вывода каждого ресурса в отдельную колонку, также потребуется "разворачивать" эти значения, но уже средствами СКД или более сложными запросами с использованием временных таблиц и функций агрегации.
Преимущества данного подхода:
Простота реализации: Если задача достаточно локальна, этот подход может быть проще в первоначальной реализации, так как все данные хранятся "внутри" одного объекта.
Удобство редактирования: Все ресурсы видны и редактируются на одной форме элемента справочника.
Недостатки:
Меньшая гибкость: При изменении требований (например, появлении новых видов объектов, для которых также нужны ресурсы), придется модифицировать каждый справочник, что снижает общую архитектурную гибкость.
Ограничения на производительность: При очень большом количестве элементов справочника и большом количестве строк в табличных частях могут возникнуть проблемы с производительностью, особенно при чтении и записи данных.
Сложности с отчетами: Развернуть данные табличной части в виде колонок в СКД может быть сложнее, чем с регистром сведений характеристик, если не использовать вспомогательные запросы или витрины данных.
Выбор подхода сильно зависит от конкретных требований и масштаба задачи.
"Дополнительные реквизиты и сведения" (ПВХ + Регистр сведений):
Рекомендуется, когда:
Этот подход является наиболее универсальным и рекомендуемым для большинства случаев, где требуется динамическое изменение структуры данных.
Табличная часть справочника:
Может быть использован, когда:
Этот подход проще в реализации для небольших и изолированных задач.
Критически важно также учитывать производительность. При большом объеме данных и частых обращениях к ним в отчетах, правильная индексация регистров сведений, используемых для хранения характеристик, будет иметь решающее значение для скорости работы системы.
В вашем случае, с требованием "до 15 штук могут добавить. Но для каждого измерения 1,2,3 могут быть разное количество ресурсов" и необходимостью строить отчеты, механизм "Дополнительные реквизиты и сведения" с ПВХ и РегистромСведений является наиболее предпочтительным решением, так как он обеспечивает необходимую гибкость и хорошо поддерживается платформой для формирования отчетности. Табличная часть может быть использована как более простая альтернатива, но с оговорками по масштабируемости и сложности отчетности.