При разработке конфигураций на базе Библиотеки стандартных подсистем (БСП) программисты часто сталкиваются с дилеммой: почему в системе сосуществуют две, казалось бы, дублирующие друг друга модели хранения файлов? С одной стороны, мы видим общий справочник Файлы, а с другой — множество справочников вида ИмяОбъектаПрисоединенныеФайлы. На первый взгляд их структура идентична, что вызывает логичный вопрос о целесообразности такого разделения. Разберем детально архитектурные причины этого решения и выясним, какой вариант лучше использовать в конкретных задачах.
Проанализируем предназначение каждой из схем. В БСП заложены две разные бизнес-логики работы с контентом:
Договоры. В этом случае для каждого типа владельца создается свой справочник (например, ДоговорыКонтрагентовПрисоединенныеФайлы), что позволяет тесно связать жизненный цикл файла с владельцем.Рассмотрим распространенное мнение о том, что индивидуальные справочники присоединенных файлов не поддерживают версионирование. Это глубокое заблуждение. Выясним, как это работает на самом деле:
Подсистема «Работа с файлами» в БСП универсальна. Если для конкретного справочника присоединенных файлов включена поддержка версий, система будет корректно сохранять историю изменений в подчиненном справочнике ВерсииФайлов (для общего случая) или в аналогичном механизме для присоединенных файлов. Таким образом, наличие или отсутствие версионирования не является критерием выбора между этими двумя схемами — оба варианта отлично справляются с хранением истории изменений.
Выясним причину использования множества справочников вместо одного общего с точки зрения безопасности и скорости работы. Это, пожалуй, самый важный технический аспект.
Вопрос прав (RLS): В справочнике Файлы права доступа настраиваются на уровне папок. Для системы это означает необходимость при каждом запросе проверять сложную иерархию папок, чтобы понять, имеет ли пользователь право видеть конкретный документ. Если поместить туда миллионы файлов из всех документов базы, расчет прав станет «бутылочным горлышком» производительности.
В случае с присоединенными файлами права, как правило, наследуются от объекта-владельца. Если у пользователя есть права на чтение документа РеализацияТоваровУслуг, он автоматически получает доступ к справочнику РеализацияТоваровУслугПрисоединенныеФайлы. Это работает значительно быстрее, так как не требует дополнительных проверок сложных условий доступа в базе данных.
Блокировки данных: Проанализируем ситуацию, когда тысячи пользователей одновременно загружают файлы. Если бы все они писали в одну таблицу Справочник.Файлы, риск возникновения транзакционных блокировок был бы крайне высок. Разделение на отдельные таблицы для каждого типа документа позволяет распределить нагрузку и избежать конкуренции за ресурсы базы данных.
Посмотрим, как эти механизмы связаны между собой на уровне метаданных. Несмотря на разделение, БСП использует общие алгоритмы для работы с обоими типами хранилищ. Ключевую роль здесь играет определяемый тип ВладелецФайлов.
Рассмотрим структуру этого типа. Он содержит ссылки на все объекты, которые могут иметь присоединенные файлы. Это позволяет использовать единые общие модули и формы для таких операций, как:
При интеграции подсистемы в новую конфигурацию через конструктор БСП, для каждого объекта-владельца будет создан свой справочник. Например:
// Пример структуры метаданных для справочника Номенклатура
Справочник.Номенклатура
Справочник.НоменклатураПрисоединенныеФайлы (Владелец - СправочникСсылка.Номенклатура)
Важно понимать, что обе схемы хранения поддерживают одинаковые способы физического размещения двоичных данных. Рассмотрим их:
ХранилищеЗначения. Это удобно для небольших баз, но сильно увеличивает размер файла базы данных или SQL-таблиц.Проанализируем, как выбрать правильный путь при проектировании вашей системы:
Если ваша задача — создать единый электронный архив, где документы живут своей жизнью (например, внутренние инструкции, нормативные акты, шаблоны), используйте стандартный справочник Файлы и механизм папок.
Если же вам нужно реализовать хранение вложений к учетным объектам (фотографии товаров, сканы актов, PDF-версии счетов), создавайте для каждого такого объекта отдельный справочник ПрисоединенныеФайлы. Это обеспечит максимальную производительность, логичное разделение прав доступа и отсутствие избыточных блокировок в системе.
Таким образом, наличие двух систем — это не архитектурная ошибка, а продуманный механизм масштабируемости, позволяющий эффективно решать принципиально разные бизнес-задачи в рамках одной платформы.