Как определить, что использовать: доп. реквизит, доп. сведения или штатный реквизит объекта?

При переходе на новые версии типовых конфигураций (например, 1С:Управление торговлей 11) перед разработчиком часто встает вопрос: как перенести многочисленные доработки и кастомные поля так, чтобы система осталась максимально «чистой» и легко обновляемой? В 1С существует три основных механизма для хранения дополнительных данных: штатные реквизиты (в конфигурации или расширении), дополнительные реквизиты и дополнительные сведения. Каждый из них имеет свои технические особенности, ограничения по производительности и нюансы в администрировании. Разберем подробно, какой механизм выбрать в зависимости от конкретной задачи.

Механизм дополнительных сведений

Рассмотрим в первую очередь дополнительные сведения, так как это наиболее «щадящий» для системы вариант. Этот механизм базируется на использовании общего регистра сведений (обычно ДополнительныеСведения), где данные хранятся в разрезе объектов (измерения Объект и Свойство).

Ключевые особенности и преимущества:

• Независимость от объекта: Запись дополнительных сведений происходит в отдельный регистр. Это означает, что для изменения значения поля нам не нужно вызывать метод Записать() самого документа или справочника. Это критически важно для высоконагруженных систем, так как позволяет избежать блокировок объекта.
• Удобство программной работы: Проанализируем ситуацию: если нам нужно обновить какой-то статус или справочный признак фоновым заданием, дополнительные сведения будут идеальным выбором. Нам не потребуется проходить через все проверки модуля объекта при записи.
• Массовый экспорт: Данные из регистра легче извлекать одним запросом по всем объектам сразу, что удобно для миграции или выгрузки во внешние системы.

Однако помните, что дополнительные сведения обычно не выводятся на форму объекта по умолчанию в те места, где пользователь привык видеть важные данные. Они чаще всего доступны по отдельной кнопке «Дополнительные сведения» на панели инструментов.

Механизм дополнительных реквизитов

Дополнительные реквизиты — это часть подсистемы «Свойства» БСП. В отличие от сведений, они хранятся в специальной табличной части объекта (например, ДополнительныеРеквизиты у документа ЗаказКлиента).

Когда стоит выбрать этот вариант:

1. Когда информация должна редактироваться непосредственно в форме объекта и визуально восприниматься как его часть.
2. Если данные должны записываться строго вместе с объектом (атомарно).
3. Если вы стремитесь к максимальной «типизации» конфигурации, чтобы не вносить изменения в структуру метаданных через конфигуратор.

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

Штатные реквизиты объекта (Конфигурация и Расширения)

Если количество новых полей исчисляется десятками (как в случае автора темы — до 30 реквизитов), стоит серьезно рассмотреть добавление их в структуру объекта через расширение или напрямую в конфигурацию. Рассмотрим, почему это может быть лучше программных «костылей» БСП.

Производительность БД и SQL-запросы:

Штатный реквизит — это реальная колонка в таблице базы данных. Посмотрим на преимущества этого подхода:

• Индексация: По штатному реквизиту можно построить индекс. Если вам нужно часто искать заказы по кастомному полю в списке или фильтровать отчеты, штатный реквизит обеспечит максимальную скорость. Выполнить эффективный поиск по значению в табличной части дополнительных реквизитов (где данные хранятся вертикально) гораздо сложнее и медленнее.
• Динамические списки: Штатные поля выводятся в списки без сложных соединений (JOIN), что предотвращает «тормоза» интерфейса.
• Типы данных: В дополнительных реквизитах мы ограничены типами, которые поддерживает БСП. В конфигураторе мы вольны использовать любые составные типы или специфические объекты.

Важное замечание по ограничениям СУБД: При добавлении большого количества полей (особенно типа Строка неограниченной длины или длинных строк) нужно помнить об ограничении размера строки в MS SQL Server (около 8060 байт). Добавление 30+ объемных реквизитов может приблизить вас к этому лимиту, что вызовет ошибку при реструктуризации.

Сравнение и выбор решения

Выясним причину, по которой опытные разработчики часто выбирают разные пути для разных задач. Для этого проведем сравнительный анализ по ключевым критериям:

1. Скорость разработки и внедрения:

Доп. реквизиты создаются «на лету» в режиме 1С:Предприятие. Не нужен монопольный доступ, не нужно выгонять пользователей для обновления конфигурации. Это «быстрое» решение. Однако программная работа с ними (чтение и запись через код) требует использования функций БСП, что чуть сложнее, чем простое обращение через точку.

Для программного обращения к дополнительным свойствам мы используем методы подсистемы УправлениеСвойствами. Рассмотрим пример получения значения:

// Пример получения значения дополнительного реквизита
ЗначениеСвойства = УправлениеСвойствами.ЗначениеСвойства(СсылкаНаОбъект, "ИмяСвойства");

2. Удобство обновлений:

Штатные реквизиты в основной конфигурации делают её «снятой с поддержки», что усложняет жизнь при обновлении релизов. Расширения решают эту проблему, но при серьезных изменениях структуры со стороны 1С (например, если 1С сама добавит реквизит с таким же именем), расширение может «отвалиться» или потребовать переработки.

3. Бизнес-логика:

Если реквизиты нужны для всех экземпляров объектов (например, каждый Заказ Клиента обязан иметь поле «Тип доставки»), лучше использовать штатный реквизит. Если же поле нужно лишь для 5% документов (например, специфическая пометка для узкого круга клиентов), то механизм дополнительных реквизитов будет более оправдан архитектурно.

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

Подводя итог обсуждению, сформулируем алгоритм выбора:

1. Используйте штатные реквизиты (в расширении), если:
   • По этим полям требуется быстрая фильтрация, поиск или сортировка в больших списках.
   • Реквизиты используются в сложных SQL-запросах или тяжелых отчетах.
   • Поля должны заполняться обязательно для каждого объекта.
2. Используйте дополнительные реквизиты БСП, если:
   • Вы хотите сохранить конфигурацию максимально типовой.
   • Поля нужны редко и не для всех элементов.
   • Нужна возможность добавлять новые поля пользователем-администратором без привлечения программиста.
3. Используйте дополнительные сведения, если:
   • Данные носят справочный характер.
   • Вам нужно изменять эти данные программно без блокировки основного объекта.
   • Информация не требует немедленного отображения на главной вкладке формы.

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

Таким образом, для задачи переноса 20-30 реквизитов оптимальным будет комбинированный подход: критически важные для поиска и учета поля вынести в штатные реквизиты (через расширение), а второстепенные, справочные данные перенести в механизм дополнительных свойств БСП.