При проектировании регистров накопления начинающие разработчики часто сталкиваются с вопросом: зачем нужны реквизиты, если платформа не позволяет получать по ним остатки и обороты в разрезе (группировке) через виртуальные таблицы? На первый взгляд может показаться, что это бесполезный элемент схемы данных, однако это не так. В этой статье мы подробно разберем, какую роль играют реквизиты в архитектуре 1С:Предприятие 8, как они помогают оптимизировать систему и в каких случаях их использование является единственно верным решением.
Для начала проанализируем, как платформа работает с данными регистра. Измерения определяют «разрез» хранения итогов. Каждая уникальная комбинация значений измерений создает запись в таблице итогов. Если мы добавим лишнее измерение (например, «Комментарий» или «Номер ГТД»), таблица итогов разрастется до невероятных размеров, что приведет к катастрофическому замедлению проведения документов и формирования отчетов.
Реквизиты же хранятся только в основной (физической) таблице движений. Они не участвуют в формировании итогов. Это «дополнительные сведения» о конкретном движении. Рассмотрим подробнее, как это использовать на практике.
Существует распространенное заблуждение, что реквизиты нельзя использовать в запросах к виртуальным таблицам. Это не совсем так. Рассмотрим выдержку из синтакс-помощника для параметра Условие виртуальных таблиц Обороты или ОстаткиИОбороты:
«Условие может оперировать полями регистра накопления. Оно будет использовано для ограничения состава записей, по которым будут выбираться обороты. То есть условие будет применяться к исходным записям, а не к уже отобранным».
Разберем это на примере. Допустим, у нас есть регистр Продажи и мы добавили реквизит ВидОперации. Нам нужно получить обороты только по определенному виду операции. Мы можем написать запрос следующим образом:
ВЫБРАТЬ
ПродажиОбороты.Номенклатура,
ПродажиОбороты.КоличествоОборот
ИЗ
РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, , ВидОперации = &НужныйВид) КАК ПродажиОбороты
В данном случае платформа на уровне СУБД сначала отфильтрует физические записи по реквизиту ВидОперации, а уже затем начнет суммировать ресурсы. Это гораздо эффективнее, чем делать выборку из физической таблицы вручную или накладывать фильтр в секции ГДЕ уже после получения итогов.
Проанализируем ситуацию: вам нужно вывести отчет по продажам, где для каждой строки должна быть указана «Ставка НДС» или «Менеджер», зафиксированные в документе. Если этих данных нет в регистре, вам придется в запросе соединять (ЛЕВОЕ СОЕДИНЕНИЕ) таблицу регистра с таблицей документа-регистратора.
При больших объемах данных такие соединения становятся «узким местом». Рассмотрим решение через реквизиты:
Менеджер.Менеджер напрямую из регистра.Это классический пример денормализации. Мы сознательно дублируем данные, чтобы избежать тяжелых операций соединения таблиц при чтении. Это критически важно в высоконагруженных системах.
Выясним еще одну важную сферу применения — распределенные базы данных и обмены. Часто бывает необходимо фильтровать данные при выгрузке. Например, в конфигурации Управление торговлей 10.3 не во всех регистрах есть измерение Организация. Если нам нужно настроить обмен так, чтобы в периферийную базу уходили движения только по одной организации, мы можем добавить реквизит Организация в нужные регистры.
При проведении документа реквизит заполняется, а правила обмена используют его для фильтрации миграции данных. Поскольку организация в данном случае не является аналитикой остатков (нам не важны остатки по организациям в этом конкретном регистре), добавлять её в измерения было бы архитектурной ошибкой, а реквизит подходит идеально.
Посмотрим на ситуацию с точки зрения «исторической правды». Данные в справочниках и документах могут меняться. Например, пользователь может зайти в старый документ и сменить там какой-то аналитический признак, не перепроводя документ (если это позволяют права). Или значение в справочнике может быть изменено.
Если же мы записываем важную информацию в реквизит регистра накопления в момент проведения, мы создаем неизменяемый слепок состояния системы на дату движения. Это незаменимо для аудита и сложных расчетов, таких как расчет себестоимости в 1С:ERP, где многие промежуточные данные и алгоритмические признаки сохраняются именно в реквизитах движений для последующего анализа фоновыми процессами расчета.
Подводя итог, выделим основные случаи, когда следует предпочесть реквизиты измерениям:
Таким образом, реквизиты регистров накопления — это мощный инструмент балансировки между детальностью хранения данных и скоростью работы системы. Умелое их использование отличает профессионального разработчика от новичка.