При проектировании метаданных может потребоваться принять решение по выбору между введением новых реквизитов и реализацией хранения дополнительной информации с использованием планов видов характеристик.
Допустим, необходимо дополнить справочник складов некоторыми данными, описывающими свойства склада. Например, может потребоваться ввести возможность хранения адреса склада, чтобы распечатывать в накладной адрес, по которому экспедитор сможет получить товар. Разумеется, это можно сделать, добавив для справочника складов новый реквизит "Адрес". С другой стороны, существует возможность реализовать, используя план видов характеристик, хранение дополнительных данных о складах в регистре сведений или в табличной части справочника.Очевидно, что эти два варианта существенно различаются и по особенностям реализации, и по возможностям использования полученного решения.
Введение реквизита является наиболее прямым способом реализации стоящей задачи. Этот вариант будет наиболее точно соответствовать реляционной модели организации хранения информации и обеспечит по большинству критериев наиболее удобное использование хранимой информации. Использование данного реквизита практически не потребует каких-либо усилий от разработчика. Система будет "хорошо знать", как работать с этим реквизитом. Поддержка такого решения со стороны платформы обеспечит и редактирование реквизита в форме, и отображение в списках, и удобный доступ в отчетах, включая, например, консоль отчетов. По данному реквизиту будет весьма эффективно выполняться поиск и другие операции. Однако введение такого реквизита потребует доработки форм и отчетов в конфигурации, чтобы разместить в них новый реквизит. Соответственно при необходимости создания еще одного реквизита необходимо будет выполнить аналогичные действия.
Реализация решения, основанного на использовании плана видов характеристик, позволит фактически ввести возможность динамического дополнения состава информации, которая будет характеризовать склады. Введение в конфигурации такого решения потребует заметно более существенных усилий от разработчика. В этом случае дополнительная информация, хранимая по складам в регистре сведений или табличной части, не будет строго соответствовать реляционной модели организации данных. Фактически, вместо введения дополнительных полей будет использоваться таблица, в которой значения этих полей будут храниться в одном поле, а другое поле будет идентифицировать саму хранимую информацию (например, Адрес склада, Объем склада, Ответственный кладовщик и т.д.). Так как система не будет иметь информации о том, что эта информация характеризует склады, то все необходимые операции необходимо будет детально отражать средствами конфигурирования. Это касается и форм ввода объектов и форм списков и любых отчетов с участием этой информации. Например, в консоли отчетов для получения отчета с отбором по такой характеристике нужно будет устанавливать связи между таблицами. Основным преимуществом в этом случае будет получение возможности динамического добавления новых характеристик без изменения конфигурации.
Однозначно разделить ситуации, когда нужно применять одно, а когда другое решение, конечно, невозможно. В общем случае рекомендуется, прежде всего, рассматривать вариант с введением нового реквизита. Можно рекомендовать реализовывать вариант с использованием планов видов характеристик только в тех случаях, когда для этого имеются достаточно веские причины. Основными аргументами за реализацию этого варианта могут являться:
Первый аргумент относится, в основном, к тиражным (универсальным) решениям, когда конфигурация внедряется в различных организациях и состав информации, характеризующей объект, может существенно зависеть от конкретной отраслевой специфики. Например, характеристики товаров сильно зависят от того, каким собственно видом номенклатуры торгует организация.
Второй аргумент может играть роль в тех случаях, когда для объектов одного вида необходимо обеспечить хранение разных свойств для разных экземпляров объектов. Например, если ведется торговля разнородными товарами.
Учитывая сложность реализации решения с использованием планов видов характеристик, можно рекомендовать поддерживать в прикладных решениях ограниченное количество применений этого варианта. Использование данного варианта только там, где это действительно необходимо, позволит обеспечить разумный компромисс между возможностями системы и затратами на поддержку решения.