Разработка и Конфигурация · 9 мин
1С: что лучше — регистр сведений или справочник
Чем регистр сведений отличается от справочника в 1С, когда какой объект использовать: критерии выбора, типичные ошибки, примеры хранения цен, статусов и настроек.
Выбор между регистром сведений и справочником — одна из базовых проектных развилок в 1С, и ошибка здесь дорого обходится: переделка структуры метаданных после запуска в эксплуатацию означает миграцию данных, переписывание запросов и регламентных операций. При этом формально оба объекта «просто хранят данные», поэтому начинающие разработчики часто выбирают по привычке или по аналогии с уже существующим решением.
Ключевое различие в природе данных. Справочник — это список сущностей, у которых есть собственная идентичность: контрагент, номенклатура, склад. Регистр сведений — это хранилище фактов, привязанных к одному или нескольким измерениям: цена товара у поставщика, курс валюты на дату, ответственный за подразделение. Факт без своих измерений не имеет смысла, сущность справочника существует сама по себе.
Ниже разобраны критерии выбора, типовые сценарии, ограничения каждого объекта и ошибки, которые чаще всего приводят к переделке конфигурации.
Чем объекты отличаются архитектурно
Справочник — это объект с собственной ссылкой, кодом и наименованием. Каждый элемент может быть использован в документах, других справочниках и регистрах как полноценная ссылка. Справочники поддерживают иерархию (группы и элементы), подчинённые справочники, предопределённые элементы и владельцев.
Регистр сведений — это таблица, где уникальность записи определяется набором измерений (и периодом, если регистр периодический). У записи регистра нет собственной ссылки, которую можно было бы передать в документ: обращение идёт через отбор по измерениям. Зато регистр умеет хранить историю значений во времени — то, чего справочник по умолчанию не умеет вовсе.
Ещё одно практическое отличие — поведение при удалении. Удаление элемента справочника контролируется ссылочной целостностью: платформа не даст удалить объект, на который есть ссылки (если не включён режим удаления без контроля). Записи регистра сведений удаляются свободно, что одновременно и удобно, и рискованно.
Когда выбирать справочник
Справочник нужен, если данные представляют собой перечень объектов учёта: контрагенты, договоры, склады, банковские счета, единицы измерения. Признаки такой ситуации: на элемент будут ссылаться документы; у элемента есть собственные реквизиты (ИНН, адрес, телефон); нужна иерархия или группировка; требуется уникальность кода или наименования.
Также справочник неизбежен, если элемент должен быть «владельцем» других данных — например, подчинённого справочника «Банковские счета» у справочника «Контрагенты». Регистр сведений такую связь владения не обеспечит: он хранит значения, а не структуру объектов.
Сценарий: список филиалов компании
Филиал — самостоятельная сущность: у него есть адрес, руководитель, график работы, на него ссылаются заказы и отгрузки. Это однозначно справочник. Попытка сделать филиалы регистром сведений сломается на первом же требовании выбрать филиал в документе — регистр не даёт ссылку для реквизита документа.
Когда выбирать регистр сведений
Регистр сведений подходит для значений, которые не существуют отдельно от своих измерений. Классические примеры из типовых конфигураций: курсы валют (измерение — валюта, период — дата), цены номенклатуры (измерения — вид цены и номенклатура), адреса и телефоны контрагентов в формате контактной информации.
Главный козырь регистра — периодичность. Если бизнес-вопрос звучит как «какая цена действовала 15 числа прошлого месяца», справочник ответить не сможет без дополнительных механизмов, а периодический регистр сведений решает это штатным методом ПолучитьПоследнее() или срезом последних в запросе.
Как выбрать объект
Сценарий: ответственные лица по подразделениям
Нужно знать, кто отвечает за подразделение, и когда ответственный менялся. Это периодический регистр сведений с измерением «Подразделение» и ресурсом «Сотрудник». Справочник здесь избыточен: «ответственность» — не сущность, а факт, привязанный к подразделению и дате.
Производительность и объём данных
При больших объёмах различия становятся ощутимыми. Справочники хранят служебные поля (ссылка, код, наименование, пометка удаления, предопределённость) и обычно содержат относительно небольшое число элементов — тысячи, редко сотни тысяч. Регистры сведений рассчитаны на миллионы записей и оптимизированы под выборки по измерениям через индексы.
Если планируется хранить, например, историю значений счётчиков по тысячам объектов ежедневно — это регистр сведений. Справочник с таким количеством элементов создаст проблемы в интерфейсе (выбор из огромного списка), в обменах данными и в полнотекстовом поиске.
Типичные ошибки при выборе
Самая частая ошибка — завести справочник «Цены» или «Курсы», где каждая новая цена создаёт новый элемент. Через год такой справочник содержит сотни тысяч элементов, выбор из него тормозит, а получить «цену на дату» можно только сортировкой по дате вручную. Правильное решение — периодический регистр сведений.
Встречается и обратная ошибка: хранить в регистре сведений то, что должно быть сущностью. Например, «договоры» как записи регистра с измерением «Контрагент». Как только потребуется сослаться на конкретный договор из документа или построить по договорам отчёт с детализацией реквизитов, придётся всё переделывать.
Проверка правильности решения
Прежде чем утверждать структуру, прогоните её через несколько контрольных вопросов. Можно ли будет сослаться на данные из документа, если это понадобится через полгода? Как будет получаться значение «на дату»? Что произойдёт при росте данных в десять раз? Кто и как будет вводить данные — удобна ли форма?
Полезно также проверить решение на тестовых данных: создайте несколько сотен записей, постройте типовой отчёт и типовую операцию ввода. Если для простого действия приходится писать неочевидный запрос или обходной код — структура выбрана неверно.
Как проверить выбор
Реквизит документа ссылается на элемент справочника напрямую
Приходится хранить в документе строку или искать запись по отбору
Получается штатным срезом последних регистра
Требуется сортировка по дате и ручной поиск
Тысячи новых записей не влияют на интерфейс
Список справочника открывается медленно, выбор затруднён
Контролируется платформой (код или ключ записи)
Дубли отлавливаются вручную
Комбинированные схемы
На практике часто нужны оба объекта одновременно. Типичная связка: справочник «Виды цен» + периодический регистр сведений «Цены номенклатуры» с измерениями «Вид цены» и «Номенклатура». Справочник описывает сущность, регистр — факты о ней. Также устроены контактная информация, штрихкоды, соответствия номенклатуры поставщиков в типовых решениях.
При проектировании такой связки держите «источник правды» один: если значение хранится в регистре, не дублируйте его реквизитом справочника «для удобства». Дублирование рано или поздно приведёт к расхождению данных, и разбираться, какое из двух значений верное, придётся вручную.
Что важно запомнить
Справочник — для сущностей, на которые ссылаются; регистр сведений — для фактов и значений, привязанных к измерениям и датам. История изменений — только регистр. Иерархия и ссылки — только справочник. При сомнениях проверяйте: может ли запись существовать сама по себе.
Частые вопросы
Можно ли хранить историю изменений реквизита справочника?
Штатно — нет, справочник хранит только текущее значение. Если нужна история, выносите изменяемый реквизит в периодический регистр сведений с измерением «ссылка на элемент справочника», а в справочнике оставляйте только неизменные атрибуты.
Что быстрее работает на больших объёмах?
Регистр сведений с правильно упорядоченными измерениями и индексами. Справочники проектировались для относительно небольших списков сущностей; сотни тысяч элементов уже создают проблемы в интерфейсе и обменах.
Можно ли сослаться на запись регистра сведений из документа?
Нет, у записи регистра сведений нет ссылки-идентификатора, которую можно сохранить в реквизите. Если такая ссылка нужна — данные должны быть справочником или документом.
Когда вместо обоих объектов достаточно константы?
Когда значение одно на всю систему и не привязано ни к чему: например, «Основная организация» или «Валюта учёта по умолчанию». Если значений несколько или они зависят от ключа — нужен регистр сведений.
Что делать, если структура уже выбрана неправильно?
Оцените объём данных и число мест использования. Обычно безопаснее создать правильный объект, написать разовую обработку переноса данных, обновить запросы и отчёты, а старый объект пометить как устаревший, чем продолжать наращивать обходные механизмы.