Чёрный пояс 1С: периодический регистр сведений или справочник - 4 сценария, где справочник выигрывает
Периодический регистр сведений или справочник - этот выбор разработчики делают несколько раз в год, и нередко выбирают инструмент, который потом приходится переделывать. Не потому что не знают синтаксис. Потому что думают о хранении, а не о запросе.
В чём вообще вопрос
Есть задача: хранить «историю признака» объекта. Например, статус контрагента (активный/заблокированный), категорию сотрудника, ставку налога по номенклатуре - всё, что меняется во времени и нужно получать «на дату».
Первое что приходит в голову - периодический регистр сведений. Одно измерение (ссылка на объект), реквизит (значение), периодичность «По позиции регистратора» или «По дате». Казалось бы, для этого и придумано.
Но это не всегда правда.
Когда регистр сведений хуже справочника
Первый сценарий - когда у «признака» есть собственные реквизиты, которые растут. Сегодня у статуса контрагента есть «значение» и «дата». Через полгода добавляется «причина», «ответственный», «документ-основание». Регистр сведений будет раздуваться в ширину. Справочник «ИсторияСтатусовКонтрагента» с подчинением к справочнику «Контрагенты» дешевле расширяется и понятнее для конечного пользователя в форме.
Второй сценарий - когда нужен ручной контроль записей. Пользователь должен видеть историю, исправлять конкретную запись (не «на дату», а «вот эту»), удалять ошибочные. В управляемом интерфейсе таблица подчинённого справочника в форме владельца - это встроенный список с возможностью редактирования. Форма периодического регистра сведений с ключом - это отдельная форма навигации, которую надо делать самому или использовать стандартный «Список», который пользователи не находят.
Третий сценарий - когда одного измерения «контрагент» недостаточно. Если ключ составной (контрагент + договор, или контрагент + склад), регистр сведений и справочник одинаково справляются с хранением. Но если бизнес просит в будущем делать иерархию, копирование настроек «от контрагента», массовую смену статусов - справочник выигрывает за счёт стандартных механизмов.
Четвёртый - производительность на чтение при отборе по значению, а не по ключу. «Дай мне всех контрагентов в статусе "заблокирован" прямо сейчас». В периодическом регистре это запрос с подзапросом (последние записи по каждому ключу) - на выборках от десятков тысяч ключей платформа не оптимизирует его автоматически. В справочнике с реквизитом «Актуален» (флаг текущей записи) - простой отбор по индексированному реквизиту. Важный нюанс: флаг «Актуален» платформа не поддерживает сама - его надо актуализировать вручную в обработчике при записи каждого нового элемента. Это дополнительная логика, но она локальная и предсказуемая.
Когда регистр сведений лучше справочника
Сценарий первый - жёсткая хронология без пробелов. Когда нужно точно восстановить значение «на любой произвольный момент времени», включая секунды между изменениями. Периодический регистр с периодичностью «По позиции регистратора» даёт это из коробки: срез последних даст правильное значение на любую метку - при условии, что все изменения проходят через регистратор и документы проводятся в хронологическом порядке. При проведении задним числом потребуется перепроведение или дополнительная логика восстановления хронологии. Справочник требует дополнительной логики для определения «актуальной на момент» записи в любом случае.
Сценарий второй - когда изменения порождаются проведением документов. Если статус контрагента меняется при проведении «Договора поставки» или «Акта проверки» - регистр сведений с регистратором связывает изменение с документом автоматически. При отмене проведения - запись исчезает. Справочниковые записи при отмене проведения надо удалять вручную в обработчике «ОбработкаПроведения».
Сценарий третий - технические данные с высокой частотой изменений. Состояние оборудования, показания счётчика, флаг «онлайн» для устройства - сотни записей в час. Справочник с историей будет раздуваться в экземпляры элементов и затруднит обычную работу со справочником (например, поиск оборудования по наименованию будет возвращать все исторические записи, если не поставить фильтр).
Вопрос, который стоит задать себе до выбора: «Как часто я буду читать эти данные - по ключу на дату, или фильтруя по значению?» Первое - регистр. Второе - справочник с актуальным флагом или материализованным текущим значением.
Критерии выбора - коротко
Регистр сведений выбирайте, когда: документ является источником изменений, нужна полная хронология «на дату», изменения технические и частые, ключ простой и не меняется.
Справочник с историей выбирайте, когда: пользователь сам редактирует историю через UI, у «записи об изменении» есть собственные поля, нужен отбор по текущему значению в большой выборке, или вы предвидите расширение ключа.
Ловушка, в которую попадают чаще всего
Начинают с периодического регистра сведений (правильно для MVP). Потом добавляют реквизиты к самому «изменению» - неправильно, регистр не очень для этого приспособлен. Потом бизнес просит форму, где «можно зайти и поправить вот эту запись от 15 марта». Регистр сведений имеет управляемую форму записи набора - она есть, но её надо открывать через ключ. Начинаются костыли.
Если уже в начале проекта видите хотя бы два пункта из списка «справочник лучше» - закладывайте справочник сразу. Переделывать через год при живой базе существенно дороже, особенно если данных накопилось много и структура начала использоваться в отчётах.
Итог
Периодический регистр сведений - инструмент для машинного учёта изменений, порождаемых документами или техническими процессами. Справочник с историческими записями - инструмент для управляемой человеком истории, которую нужно редактировать, отображать и фильтровать. Выбор определяется не «природой данных», а сценарием использования: кто пишет, кто читает, в каком разрезе.
Попробовать НОПик →