← На главную

При проектировании информационных систем на платформе 1С:Предприятие 8, особенно при разработке собственных решений или кастомизации типовых конфигураций на базе Библиотеки стандартных подсистем (БСП), разработчики часто задаются вопросом: почему механизм присоединенных файлов реализован именно через создание отдельного подчиненного справочника для каждого типа документа? На первый взгляд, хранение путей к файлам или самих двоичных данных в табличной части (ТЧ) самого документа или в общем регистре сведений (РС) кажется более простым и очевидным решением. Однако за архитектурой БСП стоят глубокие технологические и эксплуатационные причины.

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

1. Влияние на производительность и утяжеление объекта при вызове ПолучитьОбъект()

Рассмотрим, что происходит на уровне платформы 1С и СУБД, когда мы работаем с документом. Одним из ключевых методов для изменения данных объекта является метод ПолучитьОбъект(). При его вызове платформа считывает из базы данных в оперативную память весь объект целиком, включая все его реквизиты и табличные части.

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

2. Дата запрета изменения данных и закрытые периоды

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

Однако на практике оригиналы первичных документов (сканы актов, накладных, договоров с синими печатями) могут поступать от контрагентов с задержкой в несколько недель или даже месяцев. Представим ситуацию: период закрыт, но бухгалтеру необходимо прикрепить скан-копию к документу «Поступление товаров и услуг».

• Если файлы хранятся в табличной части документа, то для прикрепления файла систему придется открыть на редактирование в закрытом периоде. Это влечет за собой риск случайного изменения сумм, дат или проведения документа, что нарушит учет. Более того, у рядового пользователя просто не будет прав на обход даты запрета.
• Поскольку файлы хранятся в отдельном справочнике присоединенных файлов, физически изменяется не сам документ, а создается новый элемент справочника (или изменяется существующий), подчиненный этому документу. Документ-владелец при этом не перезаписывается и не перепроводится. Это позволяет прикреплять файлы к документам в закрытых периодах без нарушения требований безопасности учета.

3. Разграничение прав доступа (RLS) и роли пользователей

В крупных компаниях права доступа к информации строго регламентированы. Настройка ограничений доступа на уровне записей (RLS — Record Level Security) — это ресурсоемкая операция для СУБД.

Разберем две типичные проблемы, которые успешно решаются разделением справочников:

1. Разделение прав на документ и файл: Офис-менеджер или архивариус должен иметь право прикреплять сканы договоров или спецификаций, но при этом у него не должно быть прав на редактирование финансовых показателей самого документа (например, цен или проводок). Хранение файлов в отдельной сущности позволяет дать пользователю права на «Изменение» справочника файлов, оставив для самого документа права только на «Чтение».
2. Производительность RLS при работе СУБД: Если бы существовал один общий справочник или регистр для всех файлов в базе, то при чтении файлов системе приходилось бы динамически проверять права доступа к документу-владельцу через сложные соединения (JOIN) со всеми таблицами документов в базе данных. Создание индивидуального справочника присоединенных файлов для каждого типа документа (например, РеализацияТоваровУслугПрисоединенныеФайлы, ДоговорыКонтрагентовПрисоединенныеФайлы) позволяет СУБД выполнять проверку RLS по одной конкретной небольшой таблице, что критически важно для быстродействия системы.

4. Ссылочная целостность и объектная модель (почему не Регистр сведений)

Иногда возникает идея хранить связи файлов и документов в регистре сведений. На первый взгляд это кажется удобным, но регистр сведений (не подчиненный регистратору) не является объектной сущностью. У записи регистра нет уникального идентификатора (ссылки типа UUID).

Использование справочника дает фундаментальные преимущества благодаря объектной модели:

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

5. Эффективное версионирование файлов

Современные стандарты работы с документами требуют ведения истории изменений файлов. Механизм БСП поддерживает полноценное версионирование файлов. При изменении прикрепленного файла (например, проекта договора в формате Word) система не заменяет текущий файл, а создает его новую версию.

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

6. Оптимизация на уровне СУБД и ограничение файлового режима

Проанализируем технические аспекты работы баз данных под нагрузкой:

• Транзакционные блокировки: Если бы все пользователи системы одновременно прикрепляли файлы к разным документам, но запись шла в одну общую таблицу (один мега-регистр или один мега-справочник файлов), это приводило бы к постоянным блокировкам таблиц на уровне СУБД. Распределение файлов по индивидуальным справочникам для каждого вида документа минимизирует вероятность взаимных транзакционных блокировок при параллельной работе сотен пользователей.
• Ограничение файловой базы 1С: Для небольших компаний, работающих в файловом режиме, существует жесткое ограничение платформы — размер одной таблицы (одной сущности метаданных) не может превышать 4 Гб. Если бы вся информация о файлах хранилась в одной таблице, этот лимит был бы исчерпан очень быстро. Разделение по отдельным справочникам физически разносит данные по разным таблицам на диске.

7. Отделение метаданных от бинарных данных

Стоит отметить, что архитектура БСП устроена очень гибко. Сам справочник присоединенных файлов хранит только **метаданные** (имя файла, расширение, размер, автора, дату создания, статус блокировки для редактирования). Это позволяет мгновенно получать списки файлов, выполнять по ним поиск и строить отчеты.

Сами же «тяжелые» двоичные данные могут храниться тремя способами (настраивается в системе за пару кликов):

1. В томах на диске (на сетевом сервере в виде обычных файлов). Это самый рекомендуемый способ, так как база данных не раздувается.
2. В специальном общем плоском регистре сведений ДвоичныеДанныеФайлов (для баз данных SQL, где администраторы предпочитают хранить все в одном бэкапе).
3. В СУБД, но отдельно от метаданных, запрашиваясь только по требованию (когда пользователь непосредственно открывает файл).

Такой подход обеспечивает идеальный компромисс между производительностью базы данных и удобством работы пользователей.

Резюме

Использование отдельного справочника присоединенных файлов для каждого типа документа в 1С — это не усложнение архитектуры, а выверенное промышленное решение. Оно гарантирует:

• Высокую скорость работы системы при проведении и чтении документов.
• Возможность работы с файлами в закрытых для редактирования периодах.
• Гибкую и быструю настройку прав доступа (RLS).
• Надежную ссылочную целостность и защиту данных от случайного удаления.
• Масштабируемость базы данных при росте объемов информации.