Чем отличается регистр сведений от справочника в 1С

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

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

Ниже разберём структурные отличия, критерии выбора, типовые сценарии и ошибки, а также покажем, как проверить правильность решения на практике.

Структурные отличия двух объектов

Справочник состоит из предопределённых полей (код, наименование, владелец, родитель при иерархии) и произвольных реквизитов и табличных частей. Каждый элемент справочника — это объект с уникальной ссылкой, которую можно хранить в реквизитах документов, других справочников и регистров. Именно ссылочность — ключевое свойство справочника.

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

Когда выбирать справочник

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

Второй признак — потребность в иерархии или группировке. Если элементы нужно раскладывать по папкам («Электроника → Ноутбуки → Игровые»), выбора нет: регистр сведений иерархию не поддерживает. Третий признак — необходимость уникального кода и человекочитаемого наименования как стандартных полей.

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

Когда выбирать регистр сведений

Регистр сведений — правильный выбор для хранения характеристик, цен, курсов, настроек и соответствий. Классические примеры из типовых конфигураций: «Курсы валют», «Цены номенклатуры», «Штрихкоды номенклатуры», «Адреса контрагентов». Общее у них одно: данные не имеют смысла сами по себе, без объекта, к которому они привязаны.

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

Ещё одно преимущество — контроль уникальности по ключу. Платформа не позволит создать две записи с одинаковой комбинацией измерений (и периода). В справочнике такой контроль придётся программировать самостоятельно.

Практический пример: цены товаров

Рассмотрим задачу хранения цен. Неверное решение — справочник «Цены» с реквизитами «Товар», «Цена»: получаем объекты без собственного смысла, дубли цен на один товар, невозможность получить цену на дату и мусор в списках выбора.

Правильное решение — периодический регистр сведений «ЦеныНоменклатуры» с измерениями «Номенклатура» и «ТипЦен», ресурсом «Цена», подчинённый документу-регистратору «УстановкаЦен». Получение актуальной цены — запрос к срезу последних:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Цены.Цена
|ИЗ
| РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
| &Дата, Номенклатура = &Товар И ТипЦен = &ТипЦен) КАК Цены";
Запрос.УстановитьПараметр("Дата", ТекущаяДатаСеанса());
Запрос.УстановитьПараметр("Товар", Товар);
Запрос.УстановитьПараметр("ТипЦен", ТипЦен);

Такой запрос вернёт цену, действовавшую на указанную дату, без перебора записей и дополнительной логики. На справочнике аналогичный результат потребовал бы хранения дат в реквизитах, ручной сортировки и контроля дублей в коде.

// Проверка существования записи в регистре сведений
МенеджерЗаписи = РегистрыСведений.Штрихкоды.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Штрихкод = "4600000000001";
МенеджерЗаписи.Прочитать();
Если МенеджерЗаписи.Выбран() Тогда
 Сообщить("Запись найдена");
КонецЕсли;

Производительность и объём данных

Регистры сведений рассчитаны на большие объёмы: миллионы записей цен, штрихкодов, курсов — нормальная рабочая ситуация. Индексы строятся по измерениям, и выборка по ключу выполняется быстро. Справочники тоже выдерживают большие объёмы, но их назначение другое — относительно стабильный перечень сущностей, а не поток значений.

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

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

Типичные ошибки при выборе

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

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

Как проверить правильность решения

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

Полезно также посмотреть, как аналогичная задача решена в типовой конфигурации (БП, УТ, ERP): цены, курсы, штрихкоды, ответственные лица — всё это регистры сведений, а контрагенты, номенклатура, склады — справочники. Типовые решения — хороший ориентир, проверенный на больших объёмах.

Частые вопросы