Справочник и регистр сведений в 1С: ключевые отличия

В экосистеме 1С:Предприятие правильное проектирование структуры данных является фундаментом производительной и отказоустойчивой системы. Начинающие разработчики часто сталкиваются с дилеммой: где хранить информацию о свойствах объектов — в справочнике или в регистре сведений? Интуитивно кажется, что раз данные являются «сведениями», значит, им место в соответствующем регистре, однако такой подход может привести к архитектурным ошибкам и существенному усложнению логики приложения в будущем.

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

Архитектурная суть справочников

Справочники предназначены для хранения нормативно-справочной информации (НСИ), которая характеризуется относительной статичностью и длительным жизненным циклом. Это сущности реального мира или бизнес-объекты, с которыми работает пользователь: номенклатура товаров, контрагенты, сотрудники, склады или статьи затрат. Главной особенностью справочника является наличие уникального кода и наименования, а также возможность построения иерархии элементов.

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

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

⚠️ Внимание: Не следует создавать отдельные справочники для каждой мелкой классификации. Если список значений фиксирован и мал (например, «Пол» или «Тип операции»), разумнее использовать План видов характеристик или предопределенные перечисления, чтобы не засорять базу лишними таблицами.

Природа и назначение регистров сведений

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

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

Если вам нужно хранить историю изменений какого-либо параметра, то регистр сведений будет идеальным выбором. Платформа автоматически управляет актуальностью записей: при получении среза данных на конкретную дату система вернет значение, действовавшее в этот момент, игнорируя более новые или старые записи. Это избавляет от необходимости писать сложные запросы с группировками по датам.

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

Критерии выбора: когда использовать каждый объект

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

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

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

⚠️ Внимание: Хранение больших объемов динамических данных (например, ежедневных остатков или логов действий) в справочниках категорически не рекомендуется. Это приведет к деградации производительности при проведении документов и формировании отчетов.

Техническая деталь о срезах

При запросе к регистру сведений с использованием оператора СРЕЗПОСЛЕДНИХ или СРЕЗПЕРВЫХ платформа автоматически формирует оптимальный план выполнения, используя специальные служебные таблицы актуальности, что обеспечивает мгновенный отклик даже на миллионах записей.

Сравнительный анализ характеристик

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

Характеристика	Справочник	Регистр сведений
Основное назначение	Хранение НСИ и сущностей	Хранение зависимых от времени данных
Уникальность записи	По коду и наименованию	По набору измерений и периоду
Иерархия	Поддерживается (дерево)	Отсутствует (плоская структура)
Ведение истории	История изменений реквизитов	История срезов (периодичность)
Ссылочность	Является объектом ссылки	Не является объектом ссылки (таблица)

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

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

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

С другой стороны, регистры сведений созданы для эффективной работы с временными рядами. Механизм «виртуальных таблиц» позволяет разработчику писать простые запросы вида ВЫБРАТЬ ... ИЗ РегистрСведений.Цены.СРЕЗПОСЛЕДНИХ, при этом платформа сама оптимизирует выполнение, обращаясь только к актуальным данным. Это критически важно для отчетов, формируемых за большие периоды.

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

• ⚡ Используйте индексы в регистрах сведений для полей, по которым часто идет отбор.
• 🗄️ Избегайте хранения в регистрах сведений текстовых полей большого объема, если они не участвуют в отборах.
• 📉 Контролируйте размер таблиц истории справочников через регламентные задания очистки.

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

Практические примеры из разработки

Рассмотрим классическую задачу учета дополнительных характеристик товаров, таких как «Страна происхождения» или «Серия». Если страна происхождения для товара постоянна, её хранят в справочнике Номенклатура. Но если один и тот же товар может поступать из разных стран разными партиями, и нам важно знать страну именно для конкретной партии в конкретном документе, данные переносятся в регистр накопления или хранятся в документе. А вот если цена зависит от типа цены (опт, розница) и меняется во времени, создается регистр сведений «ЦеныНоменклатуры» с измерениями: Номенклатура, ТипЦены и Период.

Другой пример — учет соответствия кодов. Допустим, вам нужно хранить соответствие внутреннего кода товара кодам разных поставщиков. Создавать для каждого поставщика отдельный справочник нерационально. Лучше создать один регистр сведений «КодыПоставщиков», где измерением будет Поставщик и Номенклатура, а ресурсом — Код. Это позволит быстро получать код для любого поставщика на текущий момент.

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

Лайфхак для миграции

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

Частые ошибки проектировщиков

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

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

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

Можно ли ссылаться на запись регистра сведений из документа?

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

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

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

В чем разница между периодическим и непериодическим регистром сведений?

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

Как выбрать между регистром сведений и документом?

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

Можно ли сделать справочник периодическим?

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