Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Оптимизация проведения документа




Контрольные вопросы

; Для чего предназначен объект встроенного языка «Запрос»?

; Для чего предназначена система компоновки данных?

; Для чего предназначена схема компоновки данных?

; Для чего предназначены настройки компоновки данных?

; В чем отличие между реальными и виртуальными таблицами?

; Из каких частей состоит текст запроса, какие из них являются обязательными?

; Каковы основные синтаксические конструкции языка запросов?

; Что является источником данных запроса?

; Что такое псевдонимы в языке запросов?

; Что такое параметры запроса?

; Что такое параметры виртуальной таблицы?

; Что такое левое соединение?

; Как использовать конструктор запроса?

; Как выбрать данные в некотором периоде для отчета?

; Как упорядочить данные в отчете?

; Как использовать в отчете данные нескольких таблиц?

; Как использовать группировки в структуре отчета?

; Как получить последние значения регистра сведений?

; Как вывести в отчет иерархические данные?

; Как управлять выводом итогов по группировкам и общих итогов?

; Как создать отчет, содержащий диаграмму?

; Как использовать параметры в системе компоновки данных?

; Что такое ресурсы в системе компоновки данных?

; Что такое вычисляемые поля в системе компоновки данных?

; Как дополнить данные отчета всеми датами в группировке по периоду?

; Как создать пользовательские настройки отчета?

; В чем отличие «быстрых» настроек от остальных пользователь- ских настроек?

; Как определить состав пользовательских настроек отчета?

; Как вывести данные в виде таблицы?

; Как сделать отчет универсальным?


Оптимизация проведения документа

«Оказание услуги»

пРодолжительность

Ориентировочная продолжительность занятия – 3 часа 20 минут.

 

Теория: особенности использования ссылочных данных.............................................. 413

Повышение скорости проведения.................................................................................. 417

Автоматический расчет стоимости................................................................................. 429

Теория............................................................................................................................... 449

Как быстро посмотреть результат запроса.............................................................. 449

Оперативное и неоперативное проведение документов....................................... 450

Понятие момента времени........................................................................................ 453

Контроль остатков............................................................................................................ 455

Блокировка данных, которые читаются и изменяются при проведении.................... 458

Выделение произвольных областей модуля.................................................................. 460

В режиме «1С: Предприятие».......................................................................................... 465

Теория: устройство кеша................................................................................................. 465

Обычный кеш............................................................................................................. 466

Транзакционный кеш................................................................................................. 468

Контрольные вопросы...................................................................................................... 470


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

«Зачем это нужно? » – можете спросить вы. Тому есть три причины.

Во-первых, в обработчике события ОбработкаПроведения мы исполь- зуем обращение к реквизиту ВидНоменклатуры справочника Номенкла- тура через точку. Такое обращение может сильно замедлить скорость выполнения процедуры при больших объемах табличной части документа.

Во-вторых, руководство ООО «На все руки мастер» решило наконец-то завершить «эксперименты» по ручному вводу стоимости расходуемых материалов и перейти на автоматический расчет стоимости расходуемых материалов «по среднему».

В-третьих, при проведении документа ОказаниеУслуги необходимо контролировать остатки расходуемых товаров на складе. Если товаров не хватает, выдавать предупреждение и не проводить документ.

Поэтому изменения, вносимые нами в документ ОказаниеУслуги, будут преследовать три цели:

„ повышение скорости выполнения процедуры;

„ автоматическое определение стоимости расходуемых материалов при проведении документа;

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

Прежде чем мы приступим непосредственно к каким-либо действиям, следует сказать несколько слов об особенностях хранения и исполь- зования ссылочных данных в системе «1С: Предприятие».


 

Теория: особенности использования ссылочных данных


Занятие 14



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

Термином «ссылочные данные» мы будем обозначать данные, хранящиеся в базе данных, доступ к которым возможен при помощи объектов встроенного языка вида Ссылка: СправочникСсылка. < имя>, ДокументСсылка. < имя> и т. д. Для того чтобы дальнейшее изложение было понятнее, мы построим объяснение на примере получения ссылки на вид номенклатуры при проведении документа ОказаниеУслуги.

Не все данные, хранящиеся в базе данных, являются ссылочными. Это связано с тем, что в модели данных «1С: Предприятия» суще- ствует деление на данные, представляющие объектные сущности (справочники, планы счетов, документы и т. д. ), и данные, представ- ляющие необъектные сущности (регистры сведений, регистры нако- пления и т. д. ).

С точки зрения платформы некоторая совокупность объектных данных определяется не только значениями своих полей, но и самим фактом своего существования. Другими словами, удалив из базы некоторую совокупность объектных данных, мы не сможем вернуть систему в то же состояние, которое было до удаления. Даже если мы заново создадим ту же самую совокупность объектных данных с теми же самыми значениями полей, с точки зрения системы это будет ДРУГАЯ совокупность объектных данных.

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

Для того чтобы система могла отличить один объект базы данных от другого, каждый объект базы данных (совокупность объектных данных) имеет внутренний идентификатор. Различные объекты базы данных всегда будут иметь разные внутренние идентифика- торы. Этот идентификатор хранится вместе с остальными данными объекта в специальном поле Ссылка.

Необъектные данные хранятся в виде записей и с точки зрения системы определяются исключительно значениями своих полей.


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

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

Во всех этих случаях как раз и будет использоваться объект встро- енного языка вида Ссылка. Фактически этот объект хранит только внутренний идентификатор, находящийся в поле Ссылка.

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

 

Рис. 14. 1. Ссылка на элемент справочника «Номенклатура»

 

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

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

Поэтому обращение (листинг 14. 1) приводит к тому, что мы просто читаем данные, хранящиеся в оперативной памяти, в этом самом объекте встроенного языка (рис. 14. 2).


листинг 14. 1. Обращение к реквизиту объекта

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

 

Рис. 14. 2. Чтение данных из оперативной памяти

 

Однако когда мы обращаемся к виду номенклатуры как к реквизиту того элемента справочника, ссылка на который указана в табличной части документа (листинг 14. 2), происходит буквально следующее (рис. 14. 3).

листинг 14. 2. Обращение к реквизиту ссылки

 

 

 

Рис. 14. 3. Использование кеша объектов


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

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

После того как все данные, хранящиеся в реквизитах нужного элемента справочника и в реквизитах его табличных частей, будут считаны в кеш объектов, кеш объектов вернет запрашиваемую ссылку, хранящуюся в реквизите ВидНоменклатуры справочника Номенклатура.

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

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

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

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


Первое, чем мы займемся на этом занятии, – избавимся от «вредной» конструкции ТекСтрокаПереченьНоменклатуры. Номенклатура. ВидНо- менклатуры.

 

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...