By scanning

testing expression "Not Orders.ShipCountry="USA""

02) Inner Join result of '01)' to table 'Customers'

using index 'Customers!PrimaryKey'

join expression "Orders.CustomerID=Customers.CustomerID"

Недостаток данного запроса заключается в способе задания критерия отбора. Поскольку ограничения не используют индекс, запрос вынужден сканировать таблицу и проверять каждую запись на удовлетво­рение условию. Сканирование таблицы — слишком дорогостоящий процесс. Использование индексов сделало бы данный запрос намного более эффективным.

Повышение скорости выполнения запросов

Оптимизация запросов в Jet — процесс довольно сложный, но это не значит, что в нем невозможно разобраться. Ниже приведены советы, которые помогут ускорить выполнение запросов:

• Рекомендуется создавать индексы для всех полей, которые будут использованы для определения критерия отбора.

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

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

• В результирующем наборе не следует отображатькакие-либо лишние столбцы. Обработка и отобра­жение каждого столбца занимает дополнительное время.

• Рекомендуется воздерживаться от употребления сложных выражений в запросах.

• Следует избегать функцииIIF() (немедленное IF).IIF() оценивает и истинное, и ложное значения перед тем, как выдать результат. Если выполнять данную операцию для каждой записи, это может сильно повлиять на производительность.

• При использовании вложенных запросов рекомендуется записывать все вычисления в последнем запросе серии.

• ВместоCount([Customer]) лучше применятьCount(*), поскольку при срочной оптимизацииCount(*)обрабатывается быстрее — перед подсчетом не нужно проверять нулевые значения.

• По возможности следует пользоваться оператором Between для уменьшения количества строк в ре­зультирующем наборе вместо операторов "больше чем" и "меньше чем".

• Обычно размещение условия со стороны "один" отношения "один-ко-многим" — самый эффектив­ный способ, но не всегда. Можно попробовать передвинуть ограничение к стороне "многие", что­бы проверить, не изменится ли производительность. После каждого изменения условий отбора необходимо тщательно проверять результирующий набор.

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

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

• Внешние связи следует использовать только при крайней необходимости, поскольку они автомати­чески требуют проведения сканирования доминантной (сохраняемой) таблицы в объединении.

• Вместо SQL-операторов в коде рекомендуется использовать сохраненные запросы с параметрами. Jet уже скомпилировал запросы с параметрами и создал для них план выполнения (хотя эти планы не­доступны в SHOWPLAN.OUT). Использование скомпилированных и сохраненных запросов устраняет необходимость оценки и оптимизации SQL-строки. Access компилирует SQL-строки, использующиеся в качестве источника записей или источника строк для форм, отчетов или элементов управления, поэтому они остаются нетронутыми.

• Рекомендуется всегда использовать скомпилированные запросы.

• Для манипуляций с данными вместо DAO по возможности следует пользоваться запросами. Для решения этих задач запросы (SQL) всегда выполняются быстрее, чем DAO.

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

• При открытии набора записей только для добавления данных следуетиспользовать опциюdbAppendOnly. При этом строки не считываются.

• При использовании данных клиент/сервер необходимо тестировать запросы к серверу. Кроме того, рекомендуется ознакомиться с новыми возможностями Access 2000, имеющими отношение к архи­тектуре клиент/сервер. Запросы к серверу не всегда выполняются быстрее, чем запросы к вложен­ным серверным таблицам, но сетевой трафик при их использовании меньше.

• Большие запросы действия могут выполняться лучше, если присвоить свойствуUseTransaction зна­чение False. При проведении транзакций Access создает временные файлы. Иногда эти таблицы ста­новятся слишком большими и уменьшают скорость выполнения запросов.

• При запрашивании данных с сервера необходимо применять методыCacheStart, FillCache и EndCache для обработки данных, поступающих с сервера.

• При работе с серверными данными следует избегать локальной обработки. Локальная обработка напоминает использование сложного выраженияGroup By с ключевым словомDistinct, использо­вание оператора LIKE в текстовых полях или полях заметок, множественных агрегирующих функ­ций в перекрестном запросе или перекрестных запросов без условийORDER. Кроме того, следует избегать сложных внешних и внутренних комбинаций связей. Такие конструкции вынуждают сервер посылать громадные объемы данных на локальный PC для обработки, что значительно снижает производительность.

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

• Если это возможно, следует заполнить приложение таким же количеством тестовых данных, кото­рое будет использоваться при работе с пользователями. Механизм Jet сможет оптимизировать зап­росы, используя те статистические показатели, которые точно отражают реальные условия выполнения запросов.

• Рекомендуется индексировать поля для сортировки.

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

• Необходимо избегать использования доменных агрегирующих функций (DIookupO) для таблиц, кото­рых нет в запросе.

Запросы представляют собой наиболее сложный аспект Access. К счастью, большую часть работы по оптимизации запросов выполняет механизм Jet. Информация, изложенная в данном разделе, поможет разработчику оказать механизму Jet содействие при оптимизации. Следует проверить результаты экспери­ментов в SHOWPLAN и с помощью подпрограммPrintStatsиQueryTimer, чтобы определить, какая комбинация решений выполняется с максимальной производительностью.

Оптимизация форм

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

В начале...

При запуске приложения первое, что видят пользователи, — начальная форма. Она может представ­лять собой всплывающий экран с названием приложения и другой информацией или кнопочную панель для навигации по приложению. В любом случае из данной формы следует удалить код. Код запуска фор­мы следует записать в стандартный модуль и выполнять только те процедуры, которые необходимы для запуска приложения. Поскольку такая форма будет загружаться быстрее, она создаст у пользователя хо­рошее первое впечатление. Возможно, выполнение некоторых операций можно отложить на какое-то время. После удаления модуля из формы свойствуHasModule необходимо присвоить значение No. Это поможет создать простую форму, которая будет выполняться быстрее. Однако, изменив значение свойства HasModule, разработчик уничтожает весь код формы и код элементов управления. Перед изменением данного свойства следует убедиться, что все подпрограммы и функции размещены в стандартном моду­ле.

Начальная формане должна содержать элементы управления ActiveX. Элементы ActiveX замедляют процесс загрузки больше, чем все другие элементы управления. Если в начальной форме необходимо использовать элемент ActiveX, возможно, следует ограничить количество других элементов управления.

Вместо макросов AutoExec лучше воспользоваться опцией Startup Form.

Быстрая загрузка изображений

Использование изображений в интерфейсе приложения демонстрирует графическую мощь Access. Од­нако то, что Northwind быстро отображает фотографии сотрудников, еще не значит, что разработчик может, не задумываясь, применять графику в приложениях. В данном разделе рассматривается использо­вание графики в базе данных.

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

При загрузке формы Access должен прорисовать или визуализировать каждый элемент управления.Неудивительно, что визуализация занимает значительно больше времени, чем совмещение. Чтобы убедить­ся, что тщательно подогнанные элементы управления случайно не перекрываются, необходимо восполь­зоваться командами Format | Vertical Spacing (Формат | Расстояние по вертикали) и Format | Horizontal Spacing (Формат | Расстояние по горизонтали).

Необходимо использовать минимально возможное количество цветов графических изображений; луч­ше всего — черно-белый вариант. Чем больше количество цветов данного изображения, тем больше памяти и времени процессора требуется на его обработку.

Графические и другие большие типы данных (заметки и OLE-объекты) следует исключить из первич­ных форм, а также из начальных таблиц и запросов. Для их отображения необходимо создать отдельную форму или запрос, вызываемый только по требованию пользователя. Это предотвращает затраты времени и ресурсов, необходимых для отображения огромных объектов, в то время как, возможно, отображение данного объекта и не является обязательным. Память, используемая формами, содержащими OLE-объек-ты, не освобождается для приложения до тех пор, пока форма не будет закрыта, поэтому по окончании работы с формами их необходимо закрывать.

Основы создания быстрых форм

Единственной серьезной проблемой, значительно влияющей на производительность при использовании форм, является количество и тип элементов управления. Каждый элемент управления поглощает память и ресурсы, одни — больше, другие — меньше. Образно говоря, связанный фрейм объекта "весит" при­мерно в 40 раз больше, чем линия. Элемент управления ActiveX может быть еще "увесистее" в зависимо­сти от того, из чего он состоит и какие действия выполняет.

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

Таблица 3. Относительный "вес" элементов форм.

Некоторые элементы управления на несколько порядков "тяжелее", чем другие, поэтому для оптими­зации полезно пользоваться подстановкой. Бывает много случаев, когда список может заменяться полем со списком или подчиненной формой. Изображения могут часто использовать элемент изображения вме­сто фрейма, а элемент вкладки может помочь разделить форму на быстро загружающиеся части, поскольку визуализируются только те элементы управления, которые находятся на текущей отображаемой странице. Учитывая, что в последнее время пользователи привыкли к гипертекстовым ссылкам в Internet, можно попробовать заменить командные кнопки гиперссылками. Если имеется возможность использовать элемент управления с меньшим "весом" без ущерба для функциональности, следует воспользоваться данной воз­можностью.

Ниже приводятся несколько советов, которые помогут повысить быстродействие элементов управления:

• Рекомендуется ограничивать количество полей, отображаемых в списках и свести к минимуму число полей со списками. Кроме того, необходимо индексировать поля поиска и отображаемые поля. Сле­дует отключить опциюAutoExpand для полей со списками, установив ее в значение No. Если Access реагирует на каждый введенный символ, производительность значительно падает. Данную опцию следует использовать только тогда, когда избежать этого невозможно. Если необходимо использовать опциюAutoExpand, нужно убедиться, что поле, в котором пользователь вводит символы, является полем текстового типа. Access может использовать функциюAutoExpand только с текстовыми дан­ными. Если данные не являются текстовыми. Access вынужден затратить некоторое время на пре­образование данных и записей.

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

• Следует избегать использования ограниченных запросов в качестве основы для полей со списками или списков. Можно попытаться взять за основу единственную таблицу. Если разработчику удастся создать таблицу с помощью запроса и воссоздавать ее по мере необходимости, производительность должна быть намного выше.

• При обновлении форм или любых элементов управления, которые отображают изменившиеся дан­ные, рекомендуется применять методRequery, работающий гораздо быстрее, чем макрос Rcquery Action. Данный метод можно использовать после выполнения удалений, особенно в многопользо­вательском приложении.

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

• Следует экономно обращаться не только с количеством и типами элементов управления, размеща­емых в форме, но и с количеством полей, представленных в наборах записей форм. Хотя из таб­лицы формы всегда загружают данные быстрее, чем из запроса, здесь есть и обратная сторона. При открытии формы, основанной на таблице, загружаются все поля таблицы, даже если форма их не отображает. Бывают случаи, когда лучше открыть форму с помощью запроса, чтобы исключить ненужные поля из набора записей.

• Сортировку базового набора записей форм следует производить лишь в крайнем случае. Процесс пересортировки записей, по времени совпадающий с конфигурированием формы для отображения, может значительно замедлить открытие формы.

• При создании кода для формы (CBF) используйте ключевое словоMe. Эта константа всегда ссы­лается на активную форму и работает быстрее, чем другие ссылки.

• Рекомендуется индексировать поля Link Child и Link Master конструкции главная форма/подчиненная форма. Это позволит значительно ускорить выборку, которая часто производится данными форма­ми.

• Если пользователь не собирается редактировать записи подчиненной формы, необходимо соответ­ствующим образом установить свойства подчиненной формы. Свойства AllowEdits, AllowAppendиAllowDeletes оказывают значительное влияние на производительность, поскольку они реализуют функциональные свойства формы. Можно получить выигрыш в скорости, если избавиться от ненужных свойств. Точно так же можно получить выигрыш в скорости, если выбрать только нужные свойства. Если форма открывается для записи данных, необходимо установить ее свойства DataEntry в значениеYes, чтобы избежать ненужного считывания записи.

• Следует строго относиться к установке свойств форм и элементов управления во время выполне­ния. Данные свойства следует устанавливать только при необходимости и только в том случае, если это не вредит производительности.

• В каждом конкретном случае рекомендуется проверять, что работает быстрее — динамическое мно­жество или простой снимок.

• Так же, как при сокрытии элементов управления с помощью разрывов страниц и вкладок, можно получить выигрыш в скорости за счет сокрытия форм. Неплохой практикой является невидимая загрузка нескольких из наиболее общих форм приложения. Такая возможность может появиться при запуске или при первом обращении к форме. Для невидимой загрузки формы ее необходимо открыть путем установки параметраWindowMode в значениеacHidden:

DoCmd.OpenForm "имя_формы",,,,,acHidden

• Когда понадобится отобразить форму для пользователя, следует воспользоваться такой командой:

Forms("имя_формы").setfocus

• На тот случай, если пользователю снова понадобится форма, вместо того чтобы закрывать, ее сле-'дует скрыть. Метод Hide уберет форму с экрана, но при этом сохранит ее в памяти.