При разработке любой конфигурации на платформе 1С перед программистом встает фундаментальный вопрос: как правильно спроектировать структуру регистров? С одной стороны, мы хотим, чтобы отчеты строились мгновенно, с другой — не хотим превращать базу данных в «неповоротливого монстра» из-за избыточности информации. Разберем эту задачу на конкретном примере складского учета ТМЦ и модернизации оборудования.
Рассмотрим ситуацию: при списании запчастей нам нужно знать не только количество списанного, но и причину (ремонт, модернизация, поломка) и конкретный объект, на который ушли детали. Проектировщики часто спорят: нужно ли добавлять поле ПричинаСписания и ОбъектМодернизации в измерения регистра накопления?
Основное правило: все, что должно выводиться в качестве итогов или оборотов в разрезе аналитики в отчетах, должно быть отражено в регистрах. Обращение к данным документов из отчета (через «точку» или соединение) считается архитектурной ошибкой при работе с большими объемами данных. Однако это правило нельзя воспринимать буквально для каждого реквизита.
Для правильного построения архитектуры мы должны четко разделять задачи разных объектов:
ПричинаСписания не должна быть измерением регистра остатков. Это приведет к «расползанию» итогов и катастрофическому замедлению системы.Почему же «тащить» данные из документов в отчет — это плохо? Проанализируем ситуацию на уровне SQL-запросов. Когда мы строим отчет по виртуальной таблице регистра (например, ОстаткиИОбороты), 1С обращается к специально подготовленным таблицам итогов. Это происходит очень быстро.
Если мы добавляем в запрос левое соединение с таблицей документа (чтобы получить реквизит ПричинаСписания), СУБД вынуждена выполнять операцию JOIN для тысяч или миллионов строк. Это «убивает» кэширование и делает отчет медленным. Денормализация данных (копирование нужных полей из документа в регистр) существует именно для того, чтобы избежать этих соединений и ускорить выборку.
Если руководство хочет видеть в отчете, сколько комплектующих ушло на конкретные компьютеры, рассмотрим три варианта реализации:
Это наиболее грамотный путь с точки зрения архитектуры. Мы оставляем регистр ОстаткиТоваров чистым (только Номенклатура и Склад). Создаем второй регистр — оборотов — например, ЗатратыНаОбслуживаниеИТ.
В этом регистре мы делаем измерения:
ОбъектМодернизации (ссылка на справочник ОС или Компьютеры);Номенклатура (списанная деталь);ПричинаСписания.При проведении документа списания запись делается в оба регистра. Отчет по «причинам» строится мгновенно по второму регистру.
Если нам нужно хранить информацию о причине, но мы не планируем использовать её как фильтр в виртуальных таблицах для получения остатков, мы можем добавить ПричинаСписания как реквизит регистра накопления.
Реквизиты регистра не входят в индекс и не участвуют в расчете итогов, но они доступны в детальных записях. Это компромисс между скоростью и объемом базы.
В сложных системах (уровня ERP) используется механизм Ключей аналитики. Вместо того чтобы раздувать регистр множеством измерений, создается один вспомогательный справочник, где скомбинированы все нужные свойства. В самом регистре хранится только одна ссылка на этот справочник. Рассмотрим пример программной логики при таком подходе:
// Пример логики определения ключа аналитики при проведении
КлючАналитики = Справочники.КлючиАналитикиУчетаНоменклатуры.ПолучитьКлюч(
Номенклатура,
Склад,
ПричинаСписания,
ОбъектМодернизации
);
Движение = Движения.ОстаткиТоваров.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
Движение.Период = Дата;
Движение.АналитикаУчета = КлючАналитики;
Движение.Количество = СтрокаТовары.Количество;
Проанализируем ситуацию: что будет, если мы всё же добавим ОбъектМодернизации прямо в основной регистр остатков?
В 90% случаев (обычная поломка или продажа) это поле будет пустым. Но для 10% случаев ремонта в таблице итогов будет создаваться уникальная запись для каждого компьютера. Если компьютеров тысячи, таблица итогов вырастет в десятки раз. Это приведет к тому, что обычная проверка остатков при продаже (которая должна быть мгновенной) начнет тормозить, так как системе придется перебирать массу ненужных ей записей по объектам ремонта.
Выясним, какой путь выбрать именно вам:
Помните, что грамотная архитектура 1С — это всегда баланс между скоростью записи (проведение документа) и скоростью чтения (построение отчета). Разделение оперативных остатков и аналитических оборотов — признак профессионального подхода к разработке.