← На главную

В процессе проектирования высоконагруженных систем на платформе 1С:Предприятие перед разработчиком часто встает вопрос оптимизации объема хранимых данных. Один из классических сценариев — выбор типа данных для хранения состояния объекта в регистре сведений. Что эффективнее: хранить состояние в виде строки или завести отдельный справочник и хранить ссылку? Давайте подробно разберем, как платформа 1С и системы управления базами данных (СУБД) обрабатывают эти типы данных.

Технический размер ссылки определенного типа

Для начала проанализируем, что представляет собой ссылка в контексте хранения данных. Любая ссылка на объект метаданных (справочник, документ) в 1С:Предприятии — это уникальный идентификатор (GUID).

Ссылка определенного типа занимает ровно 16 байт.

Это значение фиксировано для полей, где в метаданных жестко указан один тип объекта (например, СправочникСсылка.Статусы). Независимо от того, насколько длинное «Наименование» или «Код» у элемента справочника, в таблице регистра, который ссылается на этот элемент, всегда будет записано ровно 16 байт бинарных данных.

Сравнение со строковым типом данных

Теперь рассмотрим альтернативу — хранение состояния в текстовом виде. Для понимания объема нам нужно знать, как 1С работает с кодировкой. Платформа использует кодировку Unicode (стандарт UCS-2), где на каждый символ выделяется фиксированное количество памяти.

В 1С каждый символ строки занимает 2 байта.

Проведем простые расчеты для сравнения:

1. Строка из 5 символов (например, «Новый») займет 10 байт.
2. Строка из 8 символов займет 16 байт.
3. Строка из 20 символов (например, «ОжидаетПодтверждения») займет 40 байт.

Таким образом, математический порог эффективности — это 8 символов. Если ваше описание состояния короче 8 символов, строка теоретически занимает меньше места. Если длиннее — ссылка становится компактнее.

Влияние составных типов данных

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

При использовании составного типа к базовым 16 байтам идентификатора добавляются служебные поля, описывающие тип ссылки. Обычно это добавляет от 1 до 4 дополнительных байт. В итоге запись может занимать 17–20 байт и более. Рассмотрим это на примере структуры таблиц SQL: для составного типа платформа может создавать отдельные колонки под каждый тип или использовать специальные типизированные поля, что в любом случае увеличивает накладные расходы на хранение каждой записи регистра.

Скрытые расходы при использовании справочников

Выясним причину, почему нельзя оценивать только размер ссылки в регистре. Если мы выбираем вариант со справочником, нам необходимо учитывать место, которое занимает сама запись в таблице этого справочника. Каждая запись справочника включает в себя:

• Собственный GUID (16 байт);
• Код (длина зависит от настроек метаданных);
• Наименование (длина * 2 байта);
• Служебные поля: ПометкаУдаления (1 байт), Предопределенный (1 байт) и другие.

Даже самый простой справочник с коротким наименованием занимает в базе около 60–100 байт на одну запись. Однако, если записей в справочнике всего 10, а записей в регистре сведений — миллионы, эти накладные расходы ничтожны по сравнению с экономией в основной таблице регистра.

Производительность и индексация

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

1. Сравнение данных: СУБД гораздо эффективнее сравнивает 16-байтовые бинарные идентификаторы (GUID), чем текстовые строки. Для процессора это одна-две операции, в то время как сравнение строк требует посимвольного перебора.
2. Индексы: Даже если вы не создаете индекс по колонке «Состояние» явно, платформа может сделать это автоматически при определенных операциях. Индексы по бинарным данным (ссылкам) работают стабильнее и быстрее, чем индексы по длинным строкам.
3. Фрагментация: Строковые значения часто ложатся в базу более плотно, если они повторяются. GUID-ы же генерируются случайным образом, что может приводить к фрагментации индексов всей таблицы регистра.

Использование перечислений как золотая середина

Если набор состояний ограничен (например, «Новый», «В работе», «Закрыт») и не будет меняться пользователем в режиме «1С:Предприятие», проанализируем вариант использования Перечисления (Enum).

С точки зрения хранения в регистре, ссылка на перечисление также занимает 16 байт. Однако перечисление лишено недостатков справочника:

• Оно не требует хранения кода, наименования и пометок удаления для каждой записи в таком объеме;
• Исключена возможность создания дублей состояний пользователями;
• Работа в запросах с перечислениями происходит максимально быстро.

Итоговые рекомендации

Рассмотрим пошаговый алгоритм выбора типа данных для хранения состояний:

1. Если состояний мало и они фиксированы — используйте Перечисления.
2. Если состояний много, они могут добавляться пользователями, а их описание (название) длиннее 8 символов — используйте Справочник. Это сэкономит место в регистре и ускорит поиск.
3. Если состояние — это просто короткая метка (1–3 символа, например «ОК», «ERR»), и логика поиска по ним не критична — допустимо использование Строки.

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