в поле, хранящем реквизит табличной

Например, если взять наш документ "ОказаниеУслуги", то в поле, хранящем реквизит табличной части "Номенклатура" на самом деле находится внутренний идентификатор, указывающий на элемент справочника "Номенклатура":

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

Движение.Материал = ТекСтрокаПереченьНоменклатуры.Номенклатура;

приводит к тому, что мы просто читаем данные, хранящиеся в оперативной памяти:

Однако когда мы обращаемся к виду номенклатуры как к реквизиту того элемента справочника, ссылка на который указана в табличной части документа:

Если ТекСтрокаПереченьНоменклатуры.Номенклатура.ВидНоменклатуры <> Перечисления.ВидыНоменклатуры.Материал Toгда[235]

произойдет буквально следующее:

Поскольку в объекте ДокументОбъект.ОказаниеУслуги есть только ссылка на элемент справочника "Номенклатура" и больше никаких данных об этом элементе нет, система возьмет эту ссылку и обратится по ней в кэш объектов, в надежде найти там данные того объекта, ссылка на который у нее есть. Если кэш объектов не будет иметь нужных данных, он обратится к базе данных с тем, чтобы прочитать все данные объекта, ссылкой на который он обладает. После того, как все данные, хранящиеся в реквизитах нужного элемента справочника и в реквизитах его табличных частей, будут считаны в кэш объектов, кэш объектов вернет запрашиваемую ссылку, хранящуюся в реквизите "ВидНоменклатуры" справочника "Номенклатура".[236]

Как несложно догадаться, подобное обращение к базе данных требует гораздо большего количества времени, нежели просто чтение из оперативной памяти. При интерактивном заполнении документа, подобные задержки ничтожно малы, по сравнению со скоростью работы пользователя. Однако при выполнении большого количества расчетов (например, при проведении больших документов, содержащих несколько тысяч строк), разница во времени может быть довольно заметной.

Узнай больше!

Более подробно об устройстве кэша объектов можно прочитать в главе "Кэш объектов" на странице 554.

Из всего вышесказанного можно сделать следующий вывод: если алгоритм проведения документа использует только те данные, которые присутствуют в реквизитах документа (и его табличных частей), вполне достаточно использовать конструктор движений документа (как это было у нас в случае с документом "ПриходнаяНакладная"). Если же в алгоритме проведения требуется анализировать дополнительные реквизиты объектов, ссылки на которые содержатся в документе, а также использовать результаты расчета итогов регистров, – следует использовать запросы для более быстрой выборки данных из базы данных.

To же самое справедливо в отношении выполнения любых участков программы, критичных по производительности. Механизм запросов лучше "читает" информационную базу и может за один раз выбрать все необходимые данные, поэтому, например, в типовых решениях вы практически не увидите использования объекта СправочникВыборка<имя>.[237]

Содержание раздела