← На главную

Когда мы планируем переносить разработки из УПП в новую конфигурацию 1С:ERP, часто возникает вопрос: где лучше хранить данные для новых объектов метаданных — в расширениях или непосредственно в основной конфигурации? Ведущие курсов активно советуют использовать только расширения, мотивируя это современными нормами и сохранением конфигурации на поддержке. Однако, у многих программистов и руководителей проектов возникают серьезные опасения по поводу сохранности данных, особенно когда речь идет о большом объеме нормативно-справочной информации (НСО).

Давайте подробно разберем эту дилемму, рассмотрим аргументы за и против каждого подхода, выявим потенциальные риски и предложим оптимальные решения на основе опыта сообщества 1С.

Особенности механизма расширений и его развитие

Механизм расширений конфигурации является одним из центральных направлений развития платформы 1С. Начиная с версии платформы 8.3.11.2867, расширения получили возможность не только изменять существующие объекты, но и добавлять собственные структуры для хранения данных, такие как справочники, документы, регистры сведений, а также реквизиты и табличные части к существующим объектам. При этом происходит "на лету" реструктуризация базы данных.

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

Аргументы в пользу расширений для хранения данных

Использование расширений для хранения данных имеет ряд существенных преимуществ, которые мы рассмотрим подробнее:

1. Упрощение обновления типовой конфигурации и сохранение на поддержке. Это ключевое преимущество. Расширения позволяют избежать снятия конфигурации с поддержки, что значительно сокращает трудозатраты на обновление и исключает необходимость ручного слияния изменений. Обновление типовой базы происходит быстрее, так как не требуется сравнение и объединение измененных объектов основной конфигурации.
2. Изолированность доработок. Расширение работает как надстройка, имеющая более высокий приоритет, чем типовая конфигурация. Это позволяет избежать прямого влияния на базовую логику программы. Мы вносим изменения, не затрагивая ядро системы.
3. Быстрое внедрение изменений. Расширения удобно передавать заказчику в виде небольшого файла, который можно подключить даже в пользовательском режиме. Это ускоряет процесс развертывания новых функций или исправлений.
4. Поддержка разделения данных. В облачных сервисах расширение может быть установлено только в одну область базы данных, что позволяет предоставлять специфический функционал отдельным клиентам, если это необходимо.
5. Возможность деактивации. Расширение можно временно отключить, чтобы проверить работу конфигурации без доработок. При этом структуры данных, добавленные расширением, не удаляются, хотя доступ к ним будет ограничен до повторного применения расширения.

Аргументы против хранения данных в расширениях и выявленные риски

Несмотря на очевидные преимущества, использование расширений для хранения данных сопряжено с определенными рисками и ограничениями, которые необходимо учитывать:

1. Риск потери данных.
   • При удалении расширения: Если расширение хранит данные в информационной базе (добавляет справочники, документы, реквизиты), при его удалении эти данные будут безвозвратно утеряны. Перед удалением система выдает предупреждение и рекомендует сделать резервную копию. Удаление расширения, расширяющего данные, является двухэтапным процессом, требующим сначала деактивации, а затем подтверждения удаления.
   • При штатном ТиИ (Тестирование и исправление): Были зафиксированы прецеденты потери данных. Например, если к справочнику добавить реквизит через расширение, то все "подчиненные" справочники могли терять владельца при ТиИ (неверная ссылка на владельца). То есть, если у контрагента добавить реквизит, то договора после ТиИ могли быть с очищенным владельцем. Некоторые пользователи сообщали, что после добавления реквизитов через расширения 1С удаляла элементы при ТиИ. Важно отметить, что многие из этих багов были поправлены в более поздних версиях платформы, но опасения остаются.
2. Проблемы с РИБ (распределенными информационными базами). До версии 8.3.12 платформы 1С не было встроенного механизма обмена расширениями в РИБ, что требовало дополнительных решений. С версии 8.3.12 обмен расширениями в РИБ реализован на уровне платформы. Однако, даже с этим функционалом, могут возникать сложности, например, необходимость монопольной загрузки, если расширение изменяет данные, а также потенциальные проблемы с синхронизацией после изменений структуры данных. Если вы планируете использование РИБ, хранение данных в основной конфигурации может быть более надежным.
3. "Отваливание" расширения и доступность данных. Если расширение было отключено, а затем предпринята попытка чтения таблиц, которые оно модифицировало, может возникнуть ошибка. Более того, если пользователи поработали и заполнили расширенные таблицы данными, а затем конфигурация прикладного решения изменилась, и при очередном запуске расширение не применилось ("отвалилось"), то данные, находящиеся в колонках, добавленных расширением, станут недоступны. Остальные данные можно будет прочитать, но запись в этот справочник будет недоступна до тех пор, пока проблема с применением расширения не будет решена.
4. Слетающие права на расширение. В некоторых случаях могут "слетать" права на расширение для пользователей, что требует постоянного восстановления этих прав вручную после любых изменений в расширении. Это может быть связано с тем, как устанавливаются права (через конфигуратор вместо профилей в предприятии).
5. Ограничения на функционал.
   • Расширениями нельзя создавать РегламентныеЗадания и изменять свойства нумерации для некоторых объектов (документы, бизнес-процессы, задачи). Эти ограничения планируется снять в будущих версиях платформы (начиная с 8.3.22).
   • Нельзя менять тип объекта метаданных (например, из справочника в документ), так как это жестко фиксируется платформой. Такие изменения возможны только в основной конфигурации.
6. Сложность анализа изменений при обновлении основной конфигурации. При обновлении основной конфигурации нет типовых средств, позволяющих автоматически определить, насколько расширение потеряло актуальность или требует доработки из-за изменений в типовой конфигурации.
7. Производительность. Большое количество новых объектов в расширении или сильно модифицированные существующие объекты могут негативно влиять на производительность. Создание отдельных таблиц для расширенных реквизитов может усложнить прямые обращения к данным на уровне SQL, требуя учета новых имен таблиц.
8. Ограничения на прямые обращения. Расширение не может напрямую обращаться ко всем объектам основной конфигурации (например, к некоторым общим модулям), что может потребовать дублирования кода или переноса нужных объектов в само расширение, увеличивая объем кода и усложняя поддержку.
9. Конфликты между несколькими расширениями. При использовании нескольких расширений может возникнуть вероятность конфликтов, приводящих к некорректной работе программы.
10. Заимствование объектов. Для работы с существующими объектами основной конфигурации их необходимо заимствовать в расширение. При этом заимствуются не только сам объект, но и все связанные с ним реквизиты и объекты, образующие их типы. Изменение контролируемых свойств заимствованных объектов в расширении (например, имени объекта) может привести к тому, что расширение не будет подключено.

Аргументы в пользу хранения данных в основной конфигурации

Несмотря на стремление сохранять конфигурацию на поддержке, бывают ситуации, когда внесение изменений непосредственно в основную конфигурацию оказывается предпочтительным или даже необходимым:

1. Высокая надежность и сохранность данных. Хранение данных в основной конфигурации обеспечивает максимальную надежность, так как мы полностью полагаемся на стандартные механизмы платформы, которые разрабатывались для хранения данных по умолчанию. Меньше рисков, связанных со спецификой работы расширений с данными.
2. Полный контроль над структурой и поведением. Мы получаем полный контроль над структурой метаданных и их поведением, без ограничений, накладываемых механизмом расширений.
3. Простота разработки без специфических "подводных камней". Разработка новых объектов непосредственно в конфигурации может быть проще для команд, не имеющих глубокого опыта работы с расширениями и их ограничениями.
4. Незначительное влияние на обновление 1С:ERP. Для таких крупных конфигураций, как 1С:ERP, процесс обновления сам по себе является достаточно трудоемким и длительным. Добавление нескольких собственных объектов (справочников, документов) вряд ли существенно увеличит время сравнения и объединения. Разница между 1 минутой и 20 минутами сравнения может быть незначительной по сравнению с общим объемом ручной работы, которая все равно потребуется при обновлении большой системы. Часто говорят, что для ERP обновление особо не ухудшится, это не БП.

Гибридные подходы и общие рекомендации

Оптимальное решение часто лежит в комбинировании подходов, учитывая конкретные потребности проекта и допустимые риски. Давайте рассмотрим несколько рекомендаций:

1. Новые ссылочные объекты в конфигурацию, остальное в расширения. Многие эксперты придерживаются мнения, что наиболее критичные и ссылочные объекты метаданных (справочники, документы, регистры, которые содержат важные для бизнеса данные) лучше добавлять в основную конфигурацию. А вот весь сопутствующий код, формы, отчеты, подписки на события, а также менее критичные данные (настройки, логи) можно размещать в расширениях. Этот подход обеспечивает баланс между надежностью хранения данных и удобством обновления.
2. Код в расширение, данные в основную. Это развитие предыдущего пункта. Если планируется создание отдельного модуля или подсистемы, которая мало связана с типовой функциональностью, ее лучше создавать в основной конфигурации. Связь с типовым функционалом тогда можно осуществлять через расширение.
3. Все в расширение, но с повышенными мерами безопасности. Если есть жесткие требования "основную не трогать вообще", тогда все доработки приходится делать в расширении. В этом случае критически важно предусмотреть при разработке расширения механизмы выгрузки (сохранения) данных из добавленных реквизитов и объектов. Всегда делайте копии и восстанавливайте их периодически. Регулярное резервное копирование базы данных — это золотое правило, независимо от способа доработки.
4. Принцип минимального вмешательства. Мы должны изменять только то, что действительно необходимо. Избегайте перехвата событий без прямой необходимости и глобальных изменений поведения форм и модулей.
5. Ведение реестра расширений и документация. Важно документировать все изменения и вести реестр расширений с их описанием, процедурами и функциями, особенно использующими аннотацию &Вместо, для упрощения обновлений и понимания взаимодействия между расширениями и конфигурацией. Для командной разработки расширения рекомендуется размещать в отдельных хранилищах, аналогично хранилищу конфигурации.
6. Минимизация количества заимствованных объектов. Не следует добавлять в расширение объекты, которые не будут использоваться в разработке, чтобы не усложнять поиск доработок и уменьшить шанс ложного срабатывания контроля изменений.
7. Проверка после обновлений. Даже при использовании расширений после обновления конфигурации все равно требуется проверять их работу. Не стоит полагаться на то, что "расширения всегда работают". Необходимо убедиться, что они применились корректно и весь функционал работает как ожидалось.
8. Актуальность информации. Мы всегда должны помнить, что платформа 1С развивается. Многие проблемы, которые возникали с расширениями в ранних версиях, уже были исправлены. Поэтому важно быть в курсе текущих возможностей и ограничений используемой версии платформы.
9. Выбор зависит от контекста. Окончательное решение о том, где хранить данные, должно приниматься с учетом специфики проекта: наличие РИБ, размер базы, допустимый риск потери данных, требования к сохранению конфигурации на поддержке и квалификация команды разработки.

В целом, расширения представляют собой мощный инструмент для доработки 1С, но требуют глубокого понимания их механики и ограничений для обеспечения надежности и безопасности системы. Наша цель — найти баланс между удобством поддержки и гарантией сохранности критически важных данных.