Роль измерений в регистрах сведений 1С

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

Центральным понятием при проектировании структуры такого регистра является измерение. Понимание того, как работают измерения, критически важно для архитектора системы, так как они формируют уникальный ключ записи. Неправильная настройка измерений может привести к дублированию данных или невозможности получить нужную информацию одним запросом.

В этой статье мы детально разберем природу измерений, их отличие от ресурсов и реквизитов, а также рассмотрим практические примеры их использования в типичных бизнес-задачах. Вы научитесь определять необходимые измерения на этапе проектирования и избегать распространенных ошибок при writing кода запросов.

Концептуальное назначение измерений

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

В отличие от регистров накопления, где измерения часто используются для группировки оборотов, в регистрах сведений они служат для адресации к конкретному состоянию объекта. Например, если вы храните курсы валют, то валюта и дата будут измерениями. Нельзя хранить два разных курса для одной и той же валюты на одну и ту же дату в рамках одного регистра с периодичностью «День».

Важно отметить, что конфигурация платформы 1С автоматически создает индекс по полям измерений. Это обеспечивает высокую скорость поиска записей по условиям, где участвуют измерения. Однако использование полей измерений в условиях отбора запроса является обязательным для эффективной работы базы данных.

⚠️ Внимание: Избыточное количество измерений приводит к раздуванию ключа записи и замедлению вставки новых данных. Добавляйте в измерения только те поля, которые действительно необходимы для уникальной идентификации строки.

Отличия измерений от ресурсов и реквизитов

Начинающие разработчики часто путают измерения с ресурсами или обычными реквизитами. Главное отличие заключается в их роли при формировании ключа. Ресурсы — это поля, которые хранят количественные или суммовые показатели, подлежащие агрегации или изменению. Значения ресурсов не участвуют в поиске уникальной записи, они являются «полезной нагрузкой», которую мы хотим получить по ключу.

Реквизиты регистра сведений — это дополнительные описательные поля, которые не входят ни в ключ (измерения), ни в сумму (ресурсы). Они используются для хранения справочной информации, относящейся к конкретной записи. Например, в регистре «КурсыВалют» курс будет ресурсом, валюта — измерением, а наименование банка, установившего курс, может быть реквизитом.

Технически в таблице регистра сведений в базе данных (SQL) поля измерений входят в первичный ключ (Primary Key). Поля ресурсов и реквизитов являются обычными колонками. Это фундаментальное различие определяет логику работы механизма записи и получения данных.

Характеристика	Измерение	Ресурс	Реквизит
Входит в уникальный ключ	Да	Нет	Нет
Индексируется автоматически	Да	Нет	Нет
Предназначение	Идентификация записи	Хранение числовых данных	Дополнительная информация
Влияние на режим записи	Критическое	Минимальное	Отсутствует

Понимание этой таблицы поможет вам правильно спроектировать метаданные. Если поле используется в отборе запроса постоянно и должно быть уникальным в связке с другими полями — это измерение. Если поле нужно просто вывести в отчет — скорее всего, это ресурс или реквизит.

Режимы записи и их влияние на измерения

Поведение регистра сведений напрямую зависит от выбранного режима записи, который тесно связан с понятием периодичности измерений. Существует три основных режима: Непериодический, Внутридневной и Подчинение регистратору. Выбор режима диктует, какие измерения будут обязательными и как система будет обрабатывать дубли.

В непериодическом регистре ключ состоит только из тех измерений, которые вы явно указали в конфигураторе. Здесь нет скрытого измерения «Период». Это идеально подходит для хранения статических справочников, например, соответствия артикулов товаров разных поставщиков. Запись с таким же набором измерений просто перезапишется.

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

// Пример структуры ключа для периодического регистра
// Ключ = (Измерение1, Измерение2, ..., Период)
// Попытка записать данные с тем же набором и тем же периодом вызовет замену записи

Режим «Подчинение регистратору» связывает жизнь записи регистра с конкретным документом. В этом случае к измерениям добавляется скрытое измерение Регистратор. Уникальность обеспечивается связкой «Измерения + Документ». Это полезно, когда нужно хранить историю изменений, привязанную к конкретным движениям документов, но без агрегации оборотов.

⚠️ Внимание: Изменение периодичности уже созданного и наполненного данными регистра сведений недопустимо без полной очистки регистра. Планируйте структуру заранее.

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

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

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

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

Рассмотрим пример получения последнего курса валюты. Здесь мы используем измерение «Валюта» для отбора и служебное поле «Период» для сортировки. Запрос должен быть построен так, чтобы СУБД могла быстро найти нужный диапазон ключей.

ВЫБРАТЬ
КурсыВалют.Валюта КАК Валюта,
КурсыВалют.Период КАК Период,
КурсыВалют.Курс КАК Курс
ИЗ
РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
КурсыВалют.Валюта = &Валюта
И КурсыВалют.Период МЕЖДУ &НачПериода И &КонПериода
УПОРЯДОЧИТЬ ПО
КурсыВалют.Период УБЫВ

Обратите внимание на использование виртуальной таблицы Последние для периодических регистров. Она позволяет получить актуальные данные без сложной логики выборки максимума периода, используя внутреннюю оптимизацию платформы по измерениям.

Частая ошибка — попытка отбора по ресурсу в условии ГДЕ. Хотя синтаксически это возможно, такой запрос будет выполняться медленно. Всегда старайтесь сужать выборку сначала по измерениям, а затем анализировать ресурсы.

Ошибки проектирования структуры регистра

Одной из самых распространенных проблем является создание «универсальных» регистров с огромным количеством измерений «на всякий случай». Это приводит к тому, что ключ записи становится слишком длинным, а заполняемость индекса падает. В результате система тратит ресурсы на поддержание структуры, которая редко используется в полном объеме.

Другая крайность — недостаток измерений. Если вы забыли включить важное поле в состав измерений, вы не сможете хранить разнородные данные для одного объекта. Придется либо создавать новый регистр, либо усложнять логику хранения, упаковывая данные в строку или структуру, что нарушает принципы реляционной базы данных.

• 🚫 Ошибка: Использование строковых полей большой длины в качестве измерений без необходимости.
• ✅ Решение: Заменяйте длинные строки ссылками на справочники, которые и будут выступать измерениями.
• ⚠️ Риск: Изменение состава измерений после начала эксплуатации требует миграции данных.

Также стоит избегать хранения в измерениях данных, которые часто меняются. Хотя технически это возможно, частое изменение ключа записи фактически означает удаление старой строки и вставку новой, что фрагментирует базу данных.

⚠️ Внимание: Интерфейс конфигуратора не позволит удалить измерение из регистра, если по нему уже есть ссылки в коде или если регистр содержит данные. Требуется аккуратная рефакторинг-процедура.

Оптимизация и индексация измерений

Платформа 1С:Предприятие автоматически создает индексы для всех измерений регистра сведений. Однако в некоторых сценариях стандартной индексации может быть недостаточно. Если вы часто выполняете выборки по подмножеству измерений или в определенном порядке сортировки, может потребоваться настройка дополнительных индексов.

В свойствах регистра сведений есть вкладка «Индексы». Здесь можно создать составной индекс, который включает не все измерения, а только их часть в специфическом порядке. Это актуально для регистров с большим количеством измерений, где основные запросы идут не по полному ключу.

Например, если у вас есть регистр с измерениями (Организация, Контрагент, Договор, Номенклатура), а вы часто ищете все товары по конкретной Организации, не указывая Контрагента, полный ключевой индекс может не сработать эффективно. Дополнительный индекс по полю «Организация» ускорит такие выборки.

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

Как проверить использование индекса?

Включите технологический журнал (ТЖ) на сервере 1С и проанализируйте события DBMSSQL или PostgreSQL. Обратите внимание на операции Table Scan вместо Index Seek.

Можно ли сделать измерение необязательным к заполнению?

Да, в свойствах измерения можно снять галочку «Ведущее» (если это ссылка) и разрешить заполнение Null. Однако это усложняет логику выборки, так как Null в SQL не равен Null, и требует особой обработки в запросах.

Влияет ли порядок измерений в конфигураторе на что-то?

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

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

СУБД выдаст ошибку при попытке записи данных. Лимит зависит от используемой базы данных (SQL Server, PostgreSQL, Oracle). Обычно это около 900 байт для кластеризованного индекса. Используйте компактные типы данных.

Можно ли использовать измерение типа «ХранениеТаблицыЗначений»?

Нет, измерения могут быть только простыми типами: Число, Строка, Дата, Ссылка, Булево, УникальныйИдентификатор. Сложные составные типы в измерениях не поддерживаются.

Как очистить регистр сведений программно?

Используйте метод РегистрСведений.Очистить() в модуле объекта или через обработку. Для периодических регистров можно удалять срезы по конкретным периодам для экономии места.