← На главную

При проектировании структуры метаданных в конфигураторе 1С перед разработчиком часто встает вопрос: как правильно настроить реквизит типа Строка (например, поле «Комментарий»), если его длина редко превышает 100–200 символов, а само поле может оставаться незаполненным? Проанализируем особенности хранения строковых типов на уровне СУБД, рассмотрим влияние настроек на производительность запросов и сформируем практические рекомендации по выбору длины.

Физическое хранение строковых данных в СУБД

В зависимости от параметров, указанных для строкового реквизита в конфигураторе (длина и признак допустимой длины), платформа 1С сопоставляет их с соответствующими типами данных СУБД (например, в MS SQL Server):

1. Строка переменной длины (ограниченная): транслируется в тип nvarchar(N). В строке таблицы выделяется служебный заголовок смещения (1–2 байта), а сами данные занимают ровно столько места, сколько символов ввел пользователь (удвоенное количество байт в кодировке Unicode плюс служебные байты длины). Если реквизит не заполнен (пустая строка), он не занимает лишнего дискового пространства и не дополняется пробелами.
2. Строка фиксированной длины: транслируется в тип nchar(N). В таблице СУБД всегда резервируется фиксированный объем памяти: заданная длина строки, умноженная на 2 байта. Если введено меньше символов, СУБД дополняет остаток строки пробелами до максимального размера.
3. Строка неограниченной длины: мапится в тип данных для больших объектов (LOB — Large Object, например nvarchar(max)). В основной строке таблицы сохраняется указатель (ссылка) на страницы LOB-хранилища, а само текстовое содержимое выносится в отдельный поток данных.

Ограничения и влияние неограниченной длины на платформу 1С

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

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

   
   ВЫБРАТЬ
       ВЫРАЗИТЬ(Документ.Комментарий КАК Строка(100)) КАК КомментарийСокращенный
   ИЗ
       Документ.РеализацияТоваровУслуг КАК Документ
   

2. Индексация и быстрый поиск: по реквизиту неограниченной длины невозможно построить стандартный индекс B-Tree. Любой поиск по точному совпадению или префиксу вызовет полное сканирование таблицы (Table Scan), что создаст высокую нагрузку на дисковую подсистему сервера баз данных.
3. Поведение динамических списков: в формах списков документов и справочников для колонок неограниченной длины платформа блокирует интерактивную сортировку по клику на заголовок колонки.
4. Накладные расходы СУБД: обращение к вынесенным страницам LOB-данных требует дополнительных операций ввода-вывода (I/O) при чтении и приводит к фрагментации страниц при частых перезаписях.

Рекомендации по выбору настроек

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

1. Для реквизитов с предсказуемым объемом данных (комментарии, примечания, наименования): выбираем строку переменной длины с достаточным лимитом (например, 100, 200 или 250 символов). Пустые значения не будут занимать лишнего места в базе, а реквизит можно будет полноценно использовать в отборах, сортировках, группировках и динамических списках.
2. Для реквизитов с непредсказуемым объемом текста: используем строку неограниченной длины только в тех случаях, когда в поле планируется хранить длинные описания, дампы ответов API, XML/JSON-тела или логи, по которым заведомо не потребуется выполнять группировки и сортировки в динамических списках.
3. Для служебных идентификаторов строго фиксированного формата: тип строка фиксированной длины применяем исключительно для кодов фиксированного формата (ИНН, КПП, GUID, штрихкоды), где длина значения всегда постоянна.