При разработке подсистемы для хранения файлов электронного документооборота (ЭДО) программисты часто сталкиваются с тем, что стандартное поле Наименование в справочниках 1С ограничено 150 символами. В то же время имена файлов ЮЗД (юридически значимых документов) могут быть значительно длиннее, особенно с учетом расширения и технических префиксов. В этой статье мы разберем, как правильно спроектировать структуру справочника, обойти ограничения платформы и обеспечить высокую производительность базы данных.
Стандартный реквизит Наименование в платформе 1С:Предприятие имеет жесткое ограничение длины. Даже если вы попытаетесь увеличить его в конфигураторе, платформа не позволит установить значение более 150 символов. Это связано с внутренней архитектурой хранения данных и индексацией.
Рассмотрим ситуацию, когда в справочник ФайлыЭДО поступает файл с длинным техническим именем. Если просто обрезать строку, пользователь не сможет идентифицировать документ. Если же пытаться использовать другие поля для поиска, нужно понимать, как это скажется на быстродействии SQL-сервера.
Разберем важный технический нюанс, упомянутый участниками обсуждения. В Microsoft SQL Server существует ограничение на размер записи индекса, которое составляет примерно 900 байт. Поскольку 1С использует двухбайтовую кодировку (Unicode) для хранения строк, каждый символ занимает 2 байта.
Проанализируем расчеты: 900 байт лимита позволяют проиндексировать строку длиной максимум 450 символов. Однако в этот лимит должны входить и другие поля индекса (например, ссылка на объект или код). Именно поэтому платформа ограничивает индексируемые поля (такие как Наименование или измерения регистров) разумным пределом, чтобы гарантировать стабильную работу на любых СУБД.
Вместо того чтобы пытаться уместить техническое имя файла в Наименование, рекомендуется формировать его по определенному шаблону, который будет полезен пользователю. Выясним, какие данные наиболее важны для идентификации файла ЭДО:
Пример формирования строки для наименования: [Тип] [Номер] от [Дата] ([Контрагент]). Такая строка практически всегда укладывается в 150 символов и делает список файлов наглядным.
Если для бизнес-логики критично хранить оригинальное имя файла (например, для последующей выгрузки на диск с тем же именем), следует разделить хранение метаданных. Разберем по шагам, как это реализовать:
ИмяФайла с типом Строка и длиной, например, 500 символов (или неограниченной длины).Наименование будем записывать сокращенную версию или шаблон из Варианта 1.Рассмотрим пример кода при записи нового файла:
Процедура ПередЗаписью(Отказ)
// Ограничиваем наименование для платформенного реквизита
Если СтрДлина(ПолноеИмяФайла) > 150 Тогда
Наименование = Лев(ПолноеИмяФайла, 147) + "...";
Иначе
Наименование = ПолноеИмяФайла;
КонецЕсли;
// Сохраняем полное имя в отдельный реквизит
ИмяФайла = ПолноеИмяФайла;
КонецПроцедуры
Если поиск по полному имени файла требуется часто, индексация длинной строки (более 150 символов) может замедлить систему. Проанализируем альтернативный метод — использование хеш-функций. Мы можем создать реквизит ХешИмени (например, тип Строка, 40 символов), куда будем записывать результат свертки имени файла (MD5 или SHA-1).
Посмотрим, какие преимущества это дает:
Помимо вопроса наименования, важно правильно определить, где физически будут лежать данные. Рассмотрим два подхода:
ХранилищеЗначения. Удобно для бэкапов (все в одном файле), но быстро раздувает размер БД.ТомаХраненияФайлов, а в справочнике файлов хранится только относительный путь. Это позволяет вынести тяжелые данные на дешевые дисковые массивы.Для файлов ЭДО, объем которых может исчисляться сотнями тысяч в год, настоятельно рекомендуется использовать хранение в томах на диске.
Подведем итог нашего исследования. Для эффективного описания файлов ЭДО в справочнике 1С лучше всего:
Наименование (150 симв.) для вывода краткой, понятной человеку информации (Тип документа + Номер).