При необходимости добавить новые данные к существующим объектам в 1С (справочникам, документам), разработчик сталкивается с выбором из трех основных инструментов: механизм дополнительных реквизитов БСП, использование расширений конфигурации или непосредственное изменение основной конфигурации. Каждый из этих способов имеет свои архитектурные особенности, влияние на производительность и риски при обновлении системы. Рассмотрим подробно каждый вариант, проанализируем их сильные и слабые стороны.
Механизм дополнительных реквизитов и сведений реализован в составе Библиотеки Стандартных Подсистем (БСП). Он предназначен в первую очередь для того, чтобы пользователи могли самостоятельно добавлять аналитику без участия программиста.
Технические особенности:
Данные хранятся по модели EAV (Entity-Attribute-Value). Это означает, что значения реквизитов не создают новых колонок в таблице объекта (например, в таблице справочника Номенклатура), а записываются в общую табличную часть ДополнительныеРеквизиты или в специальный регистр сведений.
Когда использовать:
Нюансы работы в запросах и коде:
Вопреки распространенному мнению, дополнительные реквизиты можно использовать в запросах, но это требует соединения таблиц. Выясним, как это реализовать на практике. Разберем пример запроса, где нам нужно получить значение свойства по его имени:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Товар,
ДопРеквизиты.Значение КАК Цвет
ИЗ
Справочник.Номенклатура КАК Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизиты
ПО ДопРеквизиты.Ссылка = Номенклатура.Ссылка
И ДопРеквизиты.Свойство.Имя = "Цвет_ХI" // В новых версиях БСП рекомендуется искать по полю Имя
Важное замечание по производительности: использование левых соединений с табличными частями в больших запросах существенно замедляет работу СУБД. Кроме того, такие реквизиты невозможно проиндексировать стандартными средствами платформы для ускорения поиска.
Расширения — это современный механизм кастомизации, который позволяет добавлять новые данные, не снимая основную конфигурацию с поддержки (сохраняя «замочки»).
Преимущества:
Объект.ИмяРеквизитаИзРасширения.Риски и подводные камни:
Проанализируем ситуацию с надежностью хранения данных. Существует реальный риск потери данных при работе с расширениями. Если расширение будет удалено из базы или его GUID изменится, платформа может автоматически удалить физические таблицы в СУБД, где хранились данные ваших реквизитов.
Также рассмотрим проблему обновлений. Если 1С в новом релизе изменит структуру заимствованного объекта (например, удалит документ, к которому вы добавили реквизит в расширении), расширение перестанет подключаться, и доступ к данным будет затруднен до исправления ошибок совместимости.
Проблемы с новыми объектами (MD):
Этот метод подразумевает включение возможности изменения конфигурации («снятие замочков»). Несмотря на опасения многих специалистов, это зачастую является самым надежным и производительным решением.
Почему это часто лучший выбор:
Рассмотрим аргументы в пользу этого метода. Во-первых, добавление нового реквизита в существующий объект (например, справочник Контрагенты) никак не мешает автоматическому обновлению. При сравнении и объединении новые объекты просто добавляются, не вступая в конфликт с кодом поставщика.
Преимущества:
Когда стоит снимать «замочки»:
Если реквизит является частью ключевой бизнес-логики (участвует в проведении документов, расчете себестоимости, сложных отчетах), его место — в основной конфигурации. Не стоит бояться снятия поддержки: достаточно разрешить изменения только для конкретных объектов, оставив остальные на «полном замке».
Выясним причину выбора того или иного метода, исходя из практических задач. Разберем таблицу критериев:
УправлениеСвойствами).Проанализировав все способы, можно сформулировать следующие правила выбора:
Используйте Дополнительные реквизиты БСП, если вам нужно дать пользователю инструмент для настройки аналитики «на лету» и вы не планируете использовать этот реквизит в тяжелых алгоритмах расчета.
Используйте Расширения, если вы работаете во Фреше, создаете временный патч или разрабатываете тиражное решение, которое должно подключаться к любым конфигурациям без изменения их структуры.
Используйте Основную конфигурацию для всех случаев серьезной разработки корпоративных систем. Это гарантирует сохранность данных, максимальное быстродействие и предсказуемость поведения системы при обновлении. Помните, что «фетиш на замочки» не должен идти в ущерб архитектурной чистоте и производительности вашей базы данных.
Разберем типичный пример ошибки: разработчик добавил реквизит в расширение для хранения критически важных данных (например, «Статус маркировки»), а при некорректном динамическом обновлении расширение «слетело». В итоге — остановка отгрузки и необходимость восстановления данных из бэкапа. В основной конфигурации такая ситуация практически исключена.