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

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

Определение уникальности записи

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

Выбор между измерениями и ресурсами

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

• Измерения — это ключ записи. Они входят в кластерный индекс таблицы СУБД.
• Ресурсы — это хранимые данные.

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

Оптимизация индексации: стоит ли индексировать все подряд?

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

Если вы все же решили индексировать поля, обратите внимание на следующие моменты:

1. Индексация Даты часто бывает полезна, если выборки идут по диапазонам (например, ГДЕ Дата МЕЖДУ &Начало И &Конец).
2. При создании индекса в 1С, если в индексе участвует несколько полей, 1С создает составной индекс. Порядок полей в метаданных регистра влияет на порядок полей в этом индексе.
3. Не забывайте использовать функцию «План выполнения запроса» в консоли запросов. Это единственный достоверный способ узнать, какие индексы реально используются вашей СУБД для конкретного запроса.

Рекомендуемый подход к проектированию

Для вашего случая рекомендуем придерживаться следующей стратегии:

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

Пример анализа производительности

Рассмотрим, как СУБД выполняет запрос. Если вы пишете запрос:

ВЫБРАТЬ
    РС.Документ
ИЗ
    РегистрСведений.МойРегистр КАК РС
ГДЕ
    РС.Дата = &Дата
    И РС.ПризнакБулево = ИСТИНА

Если Дата индексирована, СУБД выполнит поиск по индексу Дата, а затем отфильтрует полученный результат по значению ПризнакБулево. Если ПризнакБулево не проиндексирован, это не станет катастрофой для системы, так как фильтрация по уже отобранному набору строк (после индекса по дате) произойдет очень быстро.

В заключение: проектируйте структуру исходя из бизнес-логики (уникальность), а производительность проверяйте замерами и планами выполнения запросов, а не попытками «заиндексировать всё», что часто приводит к неоправданному замедлению процессов записи в базу данных.