При проектировании прикладных решений на платформе 1С:Предприятие разработчики регулярно сталкиваются с задачей создания текстовых реквизитов для ввода произвольной информации, например, комментариев пользователей. На первый взгляд, задача кажется тривиальной: если бизнес-требования запрашивают возможность ввода комментария длиной до 300 символов, можно просто создать строку неограниченной длины, чтобы «застраховаться» от возможных изменений требований в будущем. Однако за этим простым решением скрывается пласт глубоких архитектурных нюансов, напрямую влияющих на производительность базы данных, скорость выполнения запросов и удобство разработки.
В этой статье мы подробно разберем, почему в общем случае строк неограниченной длины следует избегать, как выбор типа данных влияет на физическую структуру СУБД, какие ограничения накладывает платформа 1С на работу со строками в запросах и отчетах СКД, а также рассмотрим лучшие практики проектирования полей комментариев.
Для начала проанализируем, как именно платформа 1С работает со строковыми типами данных на логическом уровне. В платформе существует фундаментальное разделение строковых реквизитов на две категории: строки ограниченной длины и строки неограниченной длины. Границей между ними является жестко заданный лимит.
Максимальная длина ограниченной строки в 1С составляет 1024 символа.
Если при проектировании реквизита в конфигураторе вы укажете длину 1024, платформа создаст поле ограниченной длины. Но если вам потребуется хранить хотя бы на один символ больше (1025 символов), задать такое значение в свойствах реквизита будет невозможно. В этом случае тип данных автоматически и безальтернативно перейдет в разряд строк неограниченной длины. Это важно учитывать при сборе бизнес-требований: если пользователи настаивают на «примерно 1100 символах», это автоматически означает переход к неограниченной длине со всеми вытекающими техническими последствиями.
Выбор между ограниченной строкой (например, 300 символов) и неограниченной существенно влияет на структуру таблиц в базе данных (SQL) и скорость работы системы:
NVARCHAR(300) для MS SQL). Данные этого поля хранятся непосредственно «внутри» строки таблицы, на той же странице данных (размером 8 Кб). Когда платформа 1С выполняет запрос на чтение документа или справочника, СУБД считывает всю страницу данных за одну операцию ввода-вывода (I/O). Это обеспечивает колоссальную скорость выборки, так как все данные объекта находятся рядом.NVARCHAR(MAX) или LOB-объект (Large Object). Физически такие данные хранятся в отдельных блоках вне основной таблицы. В самой строке таблицы базы данных сохраняется лишь указатель (ссылка) длиной 16 байт, указывающий на адрес физического расположения текста. Когда СУБД выполняет выборку, ей приходится совершать двойную работу: сначала прочитать основную запись, извлечь указатель, а затем выполнить дополнительное обращение к диску (или к другой области кэша), чтобы прочитать сам текст комментария. При выборке сотен тысяч записей (например, при формировании отчетов или работе динамических списков) это приводит к деградации производительности дисковой подсистемы.Выясним причину еще одной распространенной ошибки начинающих разработчиков. Если вы приняли решение использовать ограниченную строку (например, 300 символов), платформа 1С предоставляет свойство «Допустимая длина», которое может принимать два значения: «Переменная» и «Фиксированная».
Проанализируем разницу:
Всегда выбирайте значение «Переменная» для строковых реквизитов общего назначения.
Посмотрим на проблему с точки зрения разработки запросов и построения отчетов. Строки неограниченной длины накладывают жесткие ограничения на возможности языка запросов 1С:
СГРУППИРОВАТЬ ПО, сортировать результаты с помощью УПОРЯДОЧИТЬ ПО или отсекать дубли через ключевое слово РАЗЛИЧНЫЕ. Попытка выполнить такой запрос вызовет ошибку СУБД.
ВЫБРАТЬ
ВЫРАЗИТЬ(Док.Комментарий КАК СТРОКА(300)) КАК КомментарийОграниченный
ИЗ
Документ.РеализацияТоваровУслуг КАК Док
Однако здесь кроется ловушка: лимит функции ВЫРАЗИТЬ в языке запросов 1С составляет ровно 1024 символа. Вы не сможете написать ВЫРАЗИТЬ(Док.Комментарий КАК СТРОКА(1025)), компилятор платформы выдаст синтаксическую ошибку.
Если требования бизнеса все же требуют от вас возможности ввода длинных детализированных комментариев, но при этом критически важно сохранить высокую производительность системы и гибкость аналитических отчетов, рассмотрим проверенный временем паттерн проектирования.
Мы можем разделить хранение информации на два компонента:
Комментарий с типом Строка ограниченной длины (например, 150 или 300 символов) с переменной длиной. Этот реквизит выводится в списки, формы выбора, используется для быстрого поиска, группировок в отчетах.ДополнительныеДанныеОбъектов). Чтение этого поля происходит динамически — только при открытии формы конкретного документа или при формировании печатной формы, где этот комментарий действительно необходим.Такой подход позволяет динамическим спискам работать быстро, а базе данных — не перегружать дисковую подсистему лишними операциями чтения LOB-объектов при каждом пролистывании списка документов.
Подводя итог обсуждению на форуме и техническому анализу платформы, сформулируем четкие правила: