Чем грозит использование строк неограниченной длины в регистре бухгалтерии и как правильно организовать хранение описаний проводок?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса

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

Как СУБД и платформа 1С хранят строки неограниченной длины

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

Клиент-серверный вариант (MS SQL Server, PostgreSQL): поля неограниченной длины транслируются в типы больших двоичных объектов (LOB) — NVARCHAR(MAX) или TEXT. Если строка не помещается в основной странице данных, СУБД выносит ее на отдельные страницы LOB-хранилища, оставляя в базовой строке таблицы лишь указатель (16 или 24 байта). Это приводит к дополнительным операциям ввода-вывода (I/O) при каждом чтении записей.
Файловый вариант (1CD): строки неограниченной длины выносятся в отдельную таблицу блоков (BLOB-структуру). При частой перезаписи и изменении проводок это вызывает быструю фрагментацию файла базы данных и рост его размера.
Влияние на кэш СУБД: регистры бухгалтерии являются одними из самых нагруженных таблиц. Увеличение физического объема таблицы движений снижает плотность записей на странице данных в оперативной памяти сервера (Buffer Pool), что напрямую замедляет проведение документов, расчет итогов и формирование отчетов (оборотно-сальдовых ведомостей, карточек счетов).

Ограничения языка запросов и динамических списков

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

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


ВЫБРАТЬ
    ХозрасчетныйДвиженияССубконто.Период КАК Период,
    ХозрасчетныйДвиженияССубконто.Регистратор КАК Регистратор,
    ХозрасчетныйДвиженияССубконто.СчетДт КАК СчетДт,
    ХозрасчетныйДвиженияССубконто.СчетКт КАК СчетКт,
    ХозрасчетныйДвиженияССубконто.Сумма КАК Сумма,
    ВЫРАЗИТЬ(ХозрасчетныйДвиженияССубконто.Содержание КАК Строка(250)) КАК СодержаниеСокращенное
ИЗ
    РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто КАК ХозрасчетныйДвиженияССубконто
ГДЕ
    ХозрасчетныйДвиженияССубконто.Период МЕЖДУ &ДатаНачала И &ДатаОкончания
УПОРЯДОЧИТЬ ПО
    СодержаниеСокращенное

Решение 1. Ограничение длины строки фиксированным размером

Рассмотрим самый простой и действенный способ. В большинстве практических сценариев бухгалтеру не требуется бесконечный текст в теле проводки. Достаточно установить фиксированную длину — например, Строка (250), Строка (500) или Строка (1000).

Преимущества такого подхода:

Поле транслируется в обычный тип NVARCHAR(N) и хранится непосредственно в строке таблицы СУБД без создания LOB-указателей.
С полем можно свободно работать в любых запросах, динамических списках, СКД и отчетах без применения конструкции ВЫРАЗИТЬ.
Поддерживается стандартная сортировка и индексация.

Решение 2. Вынос длинных описаний в отдельный подчиненный регистр сведений

Если специфика учета действительно требует хранить объемные тексты (пояснительные записки, расшифровки расчетов к проводкам), наилучшей практикой является вынос этих данных за пределы регистра бухгалтерии в отдельный Регистр сведений.

Разберем по шагам создание такой структуры:

Создадим непериодический регистр сведений с режимом записи Подчинение регистратору (или независимый регистр).
В качестве измерений укажем:
- Регистратор (тип: ДокументСсылка);
- НомерСтрокиПроводки (тип: Число(5, 0)) или КлючСвязи (тип: УникальныйИдентификатор / Число).
В качестве ресурса добавим поле ПодробноеОписание с типом Строка (неограниченная длина).

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


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	КомментарииКПроводкам.НомерСтрокиПроводки КАК НомерСтроки,
    |	КомментарииКПроводкам.ПодробноеОписание КАК ПодробноеОписание
    |ИЗ
    |	РегистрСведений.КомментарииКПроводкам КАК КомментарииКПроводкам
    |ГДЕ
    |	КомментарииКПроводкам.Регистратор = &ТекущийДокумент";

Запрос.УстановитьПараметр("ТекущийДокумент", ДокументСсылка);
РезультатЗапроса = Запрос.Выполнить().Выгрузить();

При такой архитектуре основная таблица проводок остается максимально компактной и быстрой. Сервер СУБД не тратит ресурсы на считывание LOB-страниц при массовом расчете итогов или построении стандартных оборотно-сальдовых ведомостей, а детальные комментарии подгружаются только точечно по требованию пользователя.

Решение 3. Использование табличной части документа или механизма дополнительных сведений

Если подробные описания требуются только для ограниченного круга документов (например, исключительно для документа ОперацияБух / «Операция, введенная вручную»), анализировать их на уровне проводок не имеет смысла. Описание можно хранить непосредственно в табличной части или реквизитах самого документа, либо задействовать типовую подсистему БСП Свойства (Дополнительные реквизиты и сведения). В этом случае регистр бухгалтерии полностью освобождается от неструктурированных тяжелых текстовых данных.

← На главную