Регистры накопления. Структура хранения в базе данных

Публикация № 1061227

Программирование - Практика программирования

платформа регистры накопления SQL-запросы внутреннее устройство

168
Структура хранения регистров накопления в базе данных для платформы 1С:Предприятие 8.x. Первая часть в серии публикаций.

О регистрах накопления

В нескольких статьях представлены основные сведения о внутреннем устройстве регистров накопления, о SQL-запросах платформы при работе с ними и их изменение в зависимости от настроек регистра. Подробно описана работа платформы с разными типами регистров (остатков и накопления), а также принцип действия агрегатов.

Материалы созданы во времена платформы 8.2, поэтому некоторые моменты могут быть уже не актуальными, но основные принципы работы остались неизменными.

 
 Это информация из старого блога DevelPlatform.ru

Конкретно в этой статье речь идет о структуре хранения регистров накопления в базе данных. Все примеры из публикации Вы можете найти на GitHub.

Назначение объекта

 Платформа 1С:Предприятие 8 предоставляет разработчиком конфигураций использовать такой объект как "Регистр накопления". Регистры накопления предназначены для хранения числовых показателей в нескольких разрезах во времени. Общую информацию о возможностях и назначении этих регистров Вы можете узнать на официальном сайте. Если рассматривать его использование в рамках типовых конфигураций от фирмы "1С", то самым наглядным примером будет регистр накопления "Свободные остатки", которых хранит данные об остатках номенклатуры в разрезе складов, качества, характеристик и серий.

Здесь мы видим, что в таблице регистра хранится количество номенклатуры для каждого отдельного склада, плюс показатели для каждой позиции номенклатуры "разрезаны" по ее качеству, характеристикам и сериям. В итоге, именно регистр накопления позволяет получать доступ к этим данным более оптимальным образом, поскольку структура хранения этого регистра построена таким образом, чтобы конечные SQL-запросы, формируемые платформой, получали необходимый результат за наименьшее время и с приемлемой нагрузкой на СУБД.

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

Все эксперименты будем проводить на тестовой конфигурации с двумя регистрами накопления и двумя документами. Структура метаданных конфигурации Вы можете видеть на следующем скриншоте.

Приходный ордер, соответственно, делает приход по регистру "ОстаткиНоменклатуры", расходный ордер - расход. В регистр "ДвиженияНоменклатуры" оба документа записывают движения аналогичные регистру "ОстаткиНоменклатуры" за исключением указания вида движения, а также расходный ордер записывает показатель "Количество" с минусом. Уже можно догадаться, что вид регистра "ОстаткиНоменклатуры" - "Остатки", а "ДвиженияНоменклатуры" - "Обороты".

И так, приступим!

Таблицы и их назначение

Каждый регистр накопления состоит из нескольких таблиц базы данных.

Таблица движений

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

Главное отличие этих видов: для регистра накопления с видом "Остатки" ведется учет остатков в разрезе измерений, а также появляется возможность использовать виртуальную таблицу "Остатки". Но как это влияет на структуру хранения регистра в базе?

Для начала отметим тот факт, что вне зависимости от вида регистра в базе данных всегда присутствует таблица движений с именем "AccumRg[n]", где n  - некоторый номер, который присваивается платформой автоматически. В нашей тестовой базе были созданы две таблицы движений регистров накопления:

Структуры таблиц практически идентичные, за исключением одного поля -"_RecordKind" ("ВидДвижения"), которое присутствует только в регистре с видом "Остатки". Для регистра с видом "Обороты" нет смысла указывать вид движения, поскольку приход делается положительным показателем, расход - отрицательным. Различие между таблицами двух регистров накопления могут зависеть от состава измерений, ресурсов и реквизитов в регистре, но в нашем случае состав одинаковый.

Таблицы остатков и оборотов

Теперь поговорим о таблицах, характерных для каждого вида регистра накопления. Если вид регистра накопления установлен как "Остатки", то для него кроме таблицы движений создается таблица остатков с именем "AccumRgT[n]", если же вид регистра "Обороты", то тогда создается таблица "AccumRgTn[n]". Структуры таблиц идентичные, за исключением записываемых в них данных.

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

Его использование позволяет увеличить параллельность работы пользователей при записи движений в регистр накопления. В дальнейшем в режиме 1С:Предприятие можно включить или отключить разделение итогов для регистра. Например, если записываются движения двумя документами, при этом значения в измерениях одинаковые (например, по одной номенклатуре и складу). Тогда эти движения должны повлиять на итоги одних и тех же пар значений "Склад-Номенклатура". Чтобы не возникло ожидание на блокировке, оба документа помещают записи об изменении итогов в таблицу, но с разным значением поля "_Splitter".

Касательно данных, записываемых в каждую из таблиц. В таблице остатков ("AccumRgT[n]") хранятся лишь записи об остатках. Приведем пошаговый пример изменения записей в этой таблице при проведении документов.

1. Движения по регистру "ОстаткиНоменклатуры" отсутствуют.

Все просто: нет движений по регистру "ОстаткиНоменклатуры" - нет записей в таблице остатков этого регистра.

2. Оприходованы товары "Товар 1" и "Товар 2" на склад "Склад 1" на дату 1.01.2013. 

Вот и первый документ проведен. Мы оприходовали два товара 1 января 2013 года. Поскольку текущая дата 15.06.2013, то платформа создает записи об итоговых остатках для каждого товара и склада на каждый месяц, начиная с месяца оприходования товаров. Так, например, первые две записи с периодом "4013-02-01 00:00:00:000" показывают остатки на конец января 2013 года. Аналогично записываются остатки последующих месяцев до установленной границы рассчитанных итогов регистра (об этом речь пойдет ниже, сейчас граница установлена на 31 мая 2013 года, поэтому последняя итоговая запись по остаткам записана на период "4013-06-01 00:00:00:000". Все даты хранятся со смещением в 2000 лет, которое настраивается средствами платформы 1С. Смещение необходимо для обхода ограничения минимального значения даты в SQL Server.

Также обратите внимание на записи с периодом, где период установлен "5999-11-01 00:00:00:000". Это записи остатков номенклатуры на текущую дату. Хранение этих данных позволяет получать данные по актуальным остаткам с минимальными затратами ресурсов, т.к. не нужно обращаться к записям предыдущих периодов. Использование текущих итогов регистра определяется его настройками как и дата рассчитанных итогов. О настройках регистра мы поговорим ниже.

3. Списание товаров со склада

13 апреля 2013 был сделан расход по товарам "Товар №1", "Товар №2" и "Товар №3". Поскольку движения были сделаны в апреле, то платформа пересчитывает итоговые остатки за весь апрель и май. На скриншоте выше отмечены периоды, по которым производился пересчет итоговых остатков и не производился. Таким образом платформа сохраняет актуальные итоговые остатки как за каждый месяц, так и текущие актуальные остатки. Обратите внимание на записи, где итоговые остатки отмечены зеленым цветом. Эти записи говорят нам, что итоговый остаток равен 0. На самом деле не имеет смысла хранить остаток со значением 0, лучше если записи вообще бы не было (чтобы не создавать лишние записи в таблице). К тому же получение остатков с помощью виртуальной таблицы "Остатки" никогда не возвращает записи, если их остаток равен 0.

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

4. Последний приход товаров

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

И так, последнее проведение по регистру - приход товаров от 11 июня 2013. Так как движения по регистру сделаны в июне месяца, а граница рассчитанных итогов - это конец мая, то этот приход повлиял лишь на значения текущих остатков.

Таким образом, в таблице остатков "AccumRgT[n]" сохраняются и поддерживаются  в актуальном состоянии записи итоговых остатков по месяцам, а также текущий остатков.

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

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

Таким образом, в таблице оборотов "AccumRgTn[n]" сохранятся итоговые данные оборотов по месяцам. При этом, если в итоговые остатки делались на дату начала следующего месяца (например, для итоговых остатков за май месяц делается запись на дату 01.06.2013 00:00:00:000), то итоги по обороту платформа записывает на дату начала текущего месяца (например, итоговый оборот за май месяц будет на дату 01.05.2013 00:00:00:000).

Таблицы настроек хранения итогов

Ранее упоминалось, что для регистров накопления есть настройки, которые можно изменять в режиме 1С:Предприятие. Мы говорили об опции "Использовать текущие итоги", а также "Период рассчитанных итогов". Рассмотрим как хранятся эти настройки и дадим их краткое описание.
Начнем с места сохранения этих настроек. Для каждого регистра накопления создается таблица  "AccumRgOpt[n]", имеющая следующую структуру:

Теперь краткое описание некоторых из них:

  1. Уникальный идентификатор регистра накопления - по этому значению платформа определяет к какому именно регистру относятся эти настройки.
  2. Использовать текущие итоги - если флаг включен, то для регистров накопления с видом "Остатки" в таблице хранятся итоги на текущую дату. Выше это уже было продемонстрировано. Записи текущий итогов хранятся на дату "5999-11-01 00:00:00:000".
  3. Использовать итоги - если параметр включен, то платформа будет делать итоговые записи по остаткам или оборотам (в зависимости от вида регистра накопления).
  4. Период рассчитанных итогов - дата, начиная с которой требуется рассчитывать итоги.
  5. Использовать разделение итогов - параметр включает / отключает разделение итоговых записей для улучшения параллельности работы пользователей (ранее упоминалось о назначении поля "Splitter").

Ранее находил информацию о том, что таблица настроек хранения итогов "AccumRgOpt[n]" создается один раз для всех регистров накопления в конфигурации. Эксперимент показал, что в последних версиях платформы для каждого регистра накопления создается собственная таблица настроек хранения итогов.

Еще не все

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

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

Подробнее об агрегатах и планах обмена будет идти речь в следующих статьях.

Что дальше

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

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

Про регистры сведений также можно сделать материал, но на Инфостарт уже есть отличная статья "Регистры сведений 1С. Как это устроено" от Сергея Носкова. Новыми статьями лишь можно взглянуть на этот объект немного с другой стороны.

Но, мы можем копнуть и глубже! Если у сообщества есть интерес к внутренностями работы платформы 1С, то можно рассмотреть и другие темы:

  • Внутреннее устройство регистров бухгалтерии и регистров расчета.
  • Как платформа хранит клиентский кэш 1С, что там внутри и почему он может сломаться при динамическом обновлении.
  • Некоторые трюки с СКД.
  • Типовые индексы платформы, в том числе и в регистрах накопления, ведь эту темы мы не касались.
  • Почему отказываться от режима совместимости очень важно.
  • И многое, многое другое.

Пишите в комментариях какая тема Вам больше всего интересна! И мы что-нибудь придумаем :)

Другие ссылки

168

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. bug256 17.05.19 09:30 Сейчас в теме
Было бы здорово почитать продолжение про работу виртуальных таблиц.
Из продолжения очень хочется "Внутреннее устройство регистров бухгалтерии и регистров расчета."
texnic79; miha0713; Kinestetik; ellavs; YPermitin; +5 Ответить
3. YPermitin 3868 17.05.19 09:34 Сейчас в теме
(1) спасибо!

Отлично, принято! :)
2. klimsrv 17.05.19 09:31 Сейчас в теме
отлично, спасибо за работу
wowik; YPermitin; +2 Ответить
4. Степной 6 17.05.19 11:20 Сейчас в теме
Поддерживаю интерес по теме, связанной с регистрами расчета.
miha0713; ellavs; YPermitin; +3 Ответить
11. YPermitin 3868 17.05.19 12:12 Сейчас в теме
14. ellavs 618 17.05.19 12:43 Сейчас в теме
(4) да, про регистры расчетов было бы интересно. А то нам нужно вкрячить в одну из конфигураций по учету студентов возможность работы со стипендиями. Скорее всего именно эти регистры должны подойти, ну или почитаю про них и пойму, что не подходят ))
Kinestetik; CSiER; YPermitin; +3 Ответить
5. Chai Nic 129 17.05.19 11:31 Сейчас в теме
"Причину, почему платформа сохраняет подобные записи, а не удаляет их, не была мной найдена. Интересно было бы узнать для чего платформа оставляет такие записи. Отмечу лишь, что после пересчета итогов записи с нулевыми значениями удаляются."

Причина - приоритет быстродействия над размером. В СУБД операция UPDATE выполняется намного легче, чем DELETE.
YPermitin; +1 Ответить
6. s22 19 17.05.19 11:33 Сейчас в теме
(5) В постгре update это insert+delete.
В мсскл в режиме блокировщика есть просто update
YPermitin; +1 Ответить
7. Chai Nic 129 17.05.19 11:39 Сейчас в теме
(6) Ну, изначально 1с не ориентировалась на версионники, поэтому логично что сделали так. И кстати, никто не смотрел, на постгресе 1с тоже оставляет зануленные записи, не удаляя их?
YPermitin; +1 Ответить
8. s22 19 17.05.19 11:42 Сейчас в теме
(7) не смотрел. Но инересно
YPermitin; +1 Ответить
10. YPermitin 3868 17.05.19 12:11 Сейчас в теме
(5) во времена написания статьи еще этого не знал, но современем тайна была раскрыта :)

В принципе да, все логично сделали.
9. Lucifer93 70 17.05.19 11:50 Сейчас в теме
Очень было бы интересно почитать тему: "Как платформа хранит клиентский кэш 1С, что там внутри и почему он может сломаться при динамическом обновлении". Если будет необходима какая-либо помощь - всегда готов к сотрудничеству. Так как тема очень актуальна и хотелось бы понять что происходит.
kuzyara; PZh1753; Aggressorak; CheBurator; АлександрЯрославичъ; Kinestetik; slax; гаврюша; Aleskey_K; testnv0; Jeka44; makc33333; YPermitin; +13 Ответить
15. YPermitin 3868 17.05.19 13:13 Сейчас в теме
(9) на самом деле там много интересного.

По возможности выложу некоторые экспериментальные утилиты на GitHub. Возможно еще до того как статью напишу.
16. Lucifer93 70 17.05.19 13:19 Сейчас в теме
(15)
было бы здорово! Очень хотелось бы посмотреть.
12. zhichkin 492 17.05.19 12:25 Сейчас в теме
Хочу поддержать тему про регистры бухгалтерии и расчёта + агрегаты.
YPermitin; +1 Ответить
13. zhichkin 492 17.05.19 12:27 Сейчас в теме
Интересно было бы ещё понять почему 1С не использует indexed views, которыми по сути являются таблицы итогов.
Было бы здорово сделать сравнительный тест таблицы итогов vs indexed views.
Честно говоря, глубоко не копал - интуитивно предполагаю, что index views будут быстрее.
Скорее всего не используются из-за особенностей реализации, в том числе в разных СУБД.
Думаю доберусь до этого вопроса, когда появится немного свободного времени =)
YPermitin; +1 Ответить
27. PZh1753 3 06.09.19 13:52 Сейчас в теме
(13) 20+ лет ляпали итоговые таблички руками и тут просто так взять и отдать эту работу БД?
Им просто тяжело, эмоционально...
17. vadim1011985 65 17.05.19 13:39 Сейчас в теме
На ИТС есть краткая информация по таблицам регистров накопления

_AccumRg<n> – таблица движений регистра накопления.

_AccumRgT<n> – таблица итогов регистра накопления. Эта таблица создается в случае, если регистр накопления поддерживает остатки.

_AccumRgTn<n> – таблица оборотов регистра накопления. Эта таблица создается, если регистр поддерживает обороты.

_AccumRgOpt – таблица настроек хранения итогов регистров накопления. Эта таблица создается одна на все регистры накопления.

_AccumRgAgg<n> – таблица агрегатов регистра накопления.

_AccumRgAggOpt – таблица опций сети агрегатов.

_AccumRgSt<n> – таблица статистики регистра накопления.

_AccumRgBf<n> – таблица буфера новых оборотов регистра накопления.

_AccumRgDl<n> – таблица новых оборотов регистра накопления.

_AccumRgAggDims – таблица кодов измерений регистра накопления.

_AccumRgAggGrid – таблица сети агрегатов.

_AccumRgChngR<n> – таблица регистрации изменений регистра накопления. Создается, если регистр накопления участвует хотя бы в одном плане обмена.
18. fishca 1151 17.05.19 15:56 Сейчас в теме
Давным давно мной был создан блог DevelPlatform,

Дежавю не покидало все время в процессе чтения :D

Спасибо за возрождение на данном ресурсе!
YPermitin; +1 Ответить
19. YPermitin 3868 17.05.19 15:57 Сейчас в теме
(18) надеюсь в других новых статьях дежавю не было :)
20. AlexeyDmuhin 17.05.19 23:56 Сейчас в теме
21. Алексей Воробьев 15 19.05.19 15:12 Сейчас в теме
Спасибо за материал! Отлично, лаконично и доступно!
В таком стиле интересно все, что захотите рассказать про особенности платформы.

Про "Почему отказываться от режима совместимости очень важно" будет интересно почитать, но интерес в большинстве случаев будет скорее академический, нежели практический, поскольку если конфигурация достаточно старая, то проще будет писать (или внедрять) что-то более свежее, нежели тратить время и силы на адаптацию старой конфы...
YPermitin; +1 Ответить
22. e][tend 20.05.19 02:20 Сейчас в теме
Юрий, еще задолго до того как ваш сайт почил, у меня в закладках браузера был и ваш блог. Хотя почему был, и сейчас есть))
Мне будет интересно в принципе любая тема из обозначенных, но сильно лютую за индексы, агрегаты, хинты, скрипты, extended events, советы в общем за все, что касается темы оптимизации и быстродействия.
Спасибо!
YPermitin; +1 Ответить
23. гаврюша 2 20.05.19 10:48 Сейчас в теме
Интересно и актуально. Так же присоединяюсь к актульности тем про регистры бухгалтерии, расчета и почему слетает клиентский кэш.
24. bug256 24.05.19 11:23 Сейчас в теме
На какой платформе экспериментировали?
Платформа 8.3.13.1690
Таблица _AccumRgOpt одна для всех регистров.
На 8.3.14 по каждому регистру отдельно?
25. miha0713 26.08.19 21:57 Сейчас в теме
Спасибо огромное за цикл отличных статей!
https://infostart.ru/upload/iblock/871/8718a5c6f480372c5ea4c927a04287d2.PNG
Получается AccumRg[n] - это физическая таблица, а AccumRgТn[n] AccumRgТ[n] - виртуальные?
26. Sapiens_bru 06.09.19 09:02 Сейчас в теме
(25) Это всё физические таблицы. Просто из 1С нельзя построить запрос к таблицам AccumRgТn[n] AccumRgТ[n] напрямую. Но можно сделать запрос к виртуальной таблице, которая, возможно!! сделает запрос к дополнительным таблицам регистра. Будут ли использованы дополнительные таблицы определяется параметрами запроса и состоянием самих таблиц.
Оставьте свое сообщение