Можно ли задать длину ресурса регистра сведений 1000 символов или сделать его неограниченной длины?

При проектировании структуры регистров сведений у разработчиков часто возникает вопрос: существуют ли ограничения на длину строковых полей в ресурсах и можно ли указывать длину в 1000 символов или делать строку неограниченной длины. Разберем технические особенности работы платформы 1С:Предприятие, поведение СУБД и влияние выбранного типа данных на производительность системы.

Ограничения платформы для измерений, ресурсов и реквизитов

Проанализируем, как платформа 1С контролирует типы и длины данных для разных элементов регистра сведений:

1. Измерения регистра. На измерения накладываются строгие ограничения, поскольку они входят в состав первичного ключа и кластерного индекса таблицы. Платформа не позволит назначить измерению строковый тип неограниченной длины или строку, превышающую допустимый предел длины ключа индексации СУБД (как правило, до 1024 символов).
2. Ресурсы регистра. Для ресурсов жестких ограничений на длину строки со стороны платформы нет. Разработчик может свободно задать строку ограниченной длины (например, 1000 символов) или выбрать строку неограниченной длины. В типовых конфигурациях 1С также встречаются регистры сведений со строковыми ресурсами неограниченной длины или типом ХранилищеЗначения (например, регистр сведений ВерсииОбъектов).
3. Реквизиты регистра. Реквизиты, как и ресурсы, не входят в ключ уникальности записи и могут содержать строки любой длины.

Особенности хранения на уровне СУБД и в файловой базе данных

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

1. Строка ограниченной длины (например, 1000 символов). В реляционных СУБД для такого поля создается колонка соответствующего типа: NVARCHAR(1000) в Microsoft SQL Server или varchar(1000) в PostgreSQL. Данные сохраняются непосредственно в основной строке таблицы. Это обеспечивает быстрое постраничное чтение данных и предсказуемый размер записи.
2. Строка неограниченной длины. Платформа создает колонку типа LOB (Large Object), например, NVARCHAR(MAX) в MS SQL Server или TEXT в PostgreSQL. При превышении определенного объема такие данные выносятся СУБД за пределы основной страницы таблицы данных в специальные структуры переполнения (TOAST в PostgreSQL / LOB-страницы в MS SQL Server).
3. Файловый вариант базы данных (.1CD). Поля неограниченной длины размещаются в отдельном внутреннем блоке/файле базы данных, для которого действуют жесткие архитектурные лимиты общего объема (в зависимости от размера страницы файла базы).

Ограничения языка запросов 1С при работе с длинными строками

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

Для строк ограниченной длины (включая 1000 символов) доступны все стандартные операции языка запросов 1С: группировка, упорядочивание, соединение таблиц по условию равенства и сравнение значений.

Для строк неограниченной длины действуют строгие правила:

1. Поля неограниченной длины нельзя использовать в секциях СГРУППИРОВАТЬ ПО, УПОРЯДОЧИТЬ ПО, в операциях сравнения (=, <>, >, <), а также в условиях связи таблиц ПО.
2. Их нельзя использовать в операциях ОБЪЕДИНИТЬ без модификатора ВСЕ.
3. Если требуется сгруппировать или отсортировать данные по такому полю, необходимо явно приводить его к ограниченной длине с помощью функции ВЫРАЗИТЬ.

Посмотрим на пример правильного приведения типа в тексте запроса:

ВЫБРАТЬ
    ВЫРАЗИТЬ(Регистр.ДлинныйТекст КАК Строка(1000)) КАК ТекстСообщения,
    КОЛИЧЕСТВО(Регистр.Объект) КАК КоличествоЗаписей
ИЗ
    РегистрСведений.ЛогСобытий КАК Регистр
СГРУППИРОВАТЬ ПО
    ВЫРАЗИТЬ(Регистр.ДлинныйТекст КАК Строка(1000))

Ресурс или Реквизит: что выбрать для хранения длинного текста?

Разберем разницу между ресурсами и реквизитами в регистре сведений:

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

Однако логика работы платформы различается:

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

Практические рекомендации

Подведем итог и сформулируем правила выбора типа данных:

1. Если максимальный размер текста известен заранее (например, комментарий до 1000 символов), всегда указывайте строку переменной длины с ограничением (Строка(1000)). Это сохранит возможность гибкой работы с полем в запросах и СКД.
2. Если предполагается хранение больших произвольных текстов (дампы ответов веб-сервисов, сырые JSON/XML-структуры), допустимо использовать строку неограниченной длины или тип ХранилищеЗначения.
3. Использование ХранилищеЗначения со сжатием предпочтительно, если данные не требуется анализировать через операторы ПОДОБНО в запросах — это существенно экономит дисковое пространство базы данных.