2. Оптимизация выборки данных

Использование в приложении сложных экранных форм, содержащих различную информацию, для выборки которой из базы данных требуется множество отдельных запросов, приводит к существенному увеличению времени отклика системы на действия пользователя, увеличению нагрузки на сеть и СУБД. Особенно явно эта проблема проявляется при открытии новой формы. Таким образом, возникает задача оптимизации выборки данных при инициализации значений в элементах, расположенных на форме. Рассмотрим конкретный пример. Карточка студента, приведенная на рис.4.3, содержит 11 закладок, на которых располагаются поля ввода и встроенные списки. Поля ввода можно разделить на поля, отражающие значения атрибутов объекта «Студент» (поля атрибутов) и на поля, отражающие состояние связей этого объекта с другими объектами в базе данных («Факультет», «Отделение», «Специальность» и т.д.). Поля в ropoi о типа мы будем называть ссылочными.

Все значения атрибутов объекта можно получить за один запрос к базе данных, выбирающий одну запись из таблицы¹². Этим же запросом можно узнать и идентификаторы связанных объектов, используемые в ссылочных полях. Но каждое из этих полей содержит представление объекта, которое обычно представляет собой один из его атрибутов, но может вычисляться и исходя из атрибутов других классов (т.е. использовать полноценное представление). Кроме того, ссылочные поля на форме обычно представляются элементом управления «Поле выбора» (Combobox), который должен бьггъ заполнен всеми возможными значениями. Таким образом, для заполнения ссылочною поля требуется отдельный запрос к БД. Эти поля могут быть связаны между собой через зависимости, например, допустимые значения в полях «Отделение», «Специальность», «Кафедра» зависят от значения, выбранного в поле «Факультет»; специальность и кафедра, кроме того, зависят от отделения, кафедра от специальности и т.д.

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

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

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

1. Учет зависимостей между полями

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

При инициализации экранной формы строится граф зависимостей. Это направленный граф, который должен быть ацикличным в силу своей природы (это условие проверяется генераторами REAL-IT). Строится транзитивное замыкание этого графа, после чего отношение зависимости определяет отношение частичного порядка, что позволяет выстроить все поля ввода в линейную последовательность так, чтобы ни одно поле не зависело от полей, которые идут после него. Тогда при изменении любого поля можно инициализировать все зависимые ог него поля, идя в построенном порядке (при загрузке карточки надо пройти все ноля в эгом же порядке). При этом любое действие пользователя вызове! не более одной инициализации каждого из полей.