Периодический регистр сведений — это специализированный объект конфигурации в 1С:Предприятии 8, предназначенный для хранения истории временных изменений информации, связанной с объектами, в разрезе нескольких измерений с привязкой к периоду времени. Периодический регистр сведений является эволюцией периодических реквизитов из 1С:Предприятия 7.7, обеспечивая более гибкую и мощную модель хранения многомерных исторических данных.
Место в архитектуре 1С
Ключевое отличие от независимого регистра сведений.:
Периодический регистр сведений добавляет дополнительное измерение — период (момент времени, начиная с которого установлены значения ресурсов). Это означает, что каждая запись в периодическом регистре содержит факт установки значений ресурсов на определённый момент времени, образуя историю изменений.
Структура периодического регистра сведений
Период — встроенное измерение, определяемое при создании регистра:
- Может быть «В пределах секунды», «День», «Месяц», «Квартал», «Год»
- Определяет, с какой детализацией храниться история изменений
- Автоматически добавляется платформой как часть первичного ключа
Измерения — пользовательские ключевые поля, определяющие разрезы данных:
- Каждая комбинация измерений представляет отдельный «объект» или «разрез»
- Пример: для курсов валют измерением является «Валюта»
Ресурсы — непосредственно хранимые значения:
- Каждая запись устанавливает значения всех ресурсов в регистре на указанный момент времени
- Невозможно отметить, что какой-то ресурс «не изменился» — если запись создана, значение считается установленным
- Пример: курс валюты и кратность
Реквизиты — дополнительные данные, не входящие в первичный ключ:
Принцип работы: срезы данных
Периодический регистр сведений позволяет получить состояние данных (срез) на конкретный момент времени:
- При запросе среза система находит последние записи для каждой комбинации измерений, действительные на запрашиваемый момент
- Возвращаются ресурсы найденных записей
- Это естественно отражает семантику временно действительных данных
Если регистр содержит записи:
- 01.01.2025: USD=90, EUR=95
- 15.01.2025: USD=92, EUR=97
То срез на 10.01.2025 вернёт: USD=90, EUR=95
А срез на 20.01.2025 вернёт: USD=92, EUR=97
Проектирование структуры: один регистр или несколько?
При проектировании периодических регистров возникает критическое решение: создавать один регистр со многими ресурсами или несколько регистров с одним-двумя ресурсами каждый.
Каждая запись регистра должна отражать единый факт установки значений на момент времени. Решение о группировке ресурсов в один регистр следует принимать на основе следующих критериев:
1. Смысловая связанность данных:
Ресурсы целесообразно объединять в один регистр, если они:
- Связаны логически и представляют единый факт
- Пример: курс и кратность валюты практически всегда меняются в разное время, но объединение в один регистр упрощает работу
- Контрпример: паспортные данные (серия, номер, дата выдачи) всегда меняются вместе — логично в одном регистре
Если несколько ресурсов меняются с существенно разной частотой, это является признаком разделения на несколько регистров:
- Пример: цена товара меняется часто, минимальный складской запас — редко
- Хранение их в одном регистре приведёт к множеству записей с одинаковым значением запаса
3. Потенциальные расширения (измерения):
При проектировании следует учитывать возможность введения новых измерений в будущем:
- Если новое измерение потребует разделения регистра, лучше разделить его заранее
- Пример: если в регистр цен планируется добавить измерение «Тип цены», минимальный запас лучше выделить в отдельный регистр
4. Удобство для пользователя:
Важно, чтобы структура регистра была наглядна и понятна пользователю:
- Пользователь должен понять, что каждая запись устанавливает значения всех ресурсов
- Форма редактирования должна чётко указывать, какие значения устанавливаются одновременно
- Пример: при введении цены должно быть видно, что также устанавливается скидка
Практический пример: курсы валют
Необходимо хранить историю изменения курса и кратности валют.
Вариант 1: два отдельных регистра
- Регистр «Курсы валют»: измерение «Валюта», ресурс «Курс»
- Регистр «Кратности валют»: измерение «Валюта», ресурс «Кратность»
- Преимущества: независимые истории, кратность редко меняется
- Недостатки: при получении данных на момент нужны два среза, дополнительные таблицы
Вариант 2: один регистр с двумя ресурсами
- Регистр «Валюты»: измерение «Валюта», ресурсы «Курс» и «Кратность»
- Преимущества: один срез, проще для пользователя, быстрее
- Недостатки: записи хранятся и для каждого изменения курса (хотя кратность не меняется)
Вариант 2 обычно предпочтительнее: один регистр проще реализовывать и использовать. Можно применить сервис подстановки предыдущей кратности при вводе новой записи, чтобы пользователь не заполнял её каждый раз.
Рекомендации по производительности
Влияние на БД и производительность:
Получение данных (срезы):
- Получение среза из одного регистра с несколькими ресурсами быстрее, чем получение срезов из нескольких регистров
Запись данных:
Размер базы данных:
- Если один из ресурсов меняется часто, а другие редко, объём БД растёт быстрее при их объединении в один регистр
- Особенно критично, если один ресурс содержит большие данные (хранилище значений, картинки, бинарные данные) — такие данные целесообразно выделять в отдельный регистр
Наличие большого количества регистров сведений может снизить производительность, если требуется получать данные объекта и связанные периодические регистры на один момент. Но неправильная группировка (объединение часто и редко меняющихся данных) также приводит к неоптимальному использованию ресурсов.
Эволюция от 1С 7.7
Отличие от периодических реквизитов.:
В 1С:Предприятии 7.7 периодические реквизиты были привязаны к справочникам и их изменение было затруднено. В 1С:Предприятии 8 периодические регистры сведений:
- Независимы от справочников (хотя могут быть связаны через измерения)
- Добавление новых измерений возможно без сложной переработки (в 7.7 это было практически невозможно)
- Предоставляют гибкую многомерную модель хранения
Периодический регистр сведений — это фундаментальный компонент архитектуры 1С:Предприятия 8, обеспечивающий эффективное и гибкое хранение исторических многомерных данных, необходимых в большинстве корпоративных приложений.