Этот сайт посвящается администрированию баз данных OpenEdge Progress.
Не корысти ради, а познания для!

С уважением,
Валерий Башкатов
Сайт разработан при участии компании Progress Technologies, официального дистрибьютора Progress Software Corp. на территории стран СНГ и Латвии.

RSS RSS подписка на обновления сайта

Поиск по сайту

Лучшие материалы

Orphus System
На сайте функционирует система коррекции ошибок. Обнаружив неточность в тексте, выделите её и нажмите Ctrl+Enter



Результаты опроса: Нужны ли книги по Progress OpenEdge на русском языке? (опрос проводился с мая 2009 по ноябрь 2010)

Да, нужны. Потому что будет легче понять материал - 268
Нет, не нужны. Достаточно материалов на английском языке - 10
Не знаю, мне всё равно - 6

А знаете ли вы что..



Некоторые ключевые концепции программирования на PROGRESS 4GL


Written by © Serguey Klimoff, 2003, Russia

Коротко о главном

Данная статья описывает некоторые ключевые концепции программирования на PROGRESS 4GL


Дизайн БД и правила индексирования

  • Добавление индексов имеет как преимущества, так и недостатки. Преимущества: Увеличение скорости чтения записей из БД. Недостатки увеличение времени на создание, удаление и изменение записи в БД.
  • В запросах БД PROGRESS использует язык индексных скобок, поэтому надо стараться, чтобы как можно меньше записей находилось внутри скобки.
  • Скобки делятся на: скобки по равенству и скобки по диапазону. Скобки по равенству более приоритетны, чем по диапазону.
  • Функции, использованные в условии WHERE, не могут быть использованы для индексных скобок, поэтому в WHERE выражении не должны использоваться. Исключение: BEGINS и ROWID/RECID
  • Порядок условий в WHERE не имеет значения.
  • USE-INDEX - стараться по возможности избегать явного использования USE-INDEX. Имеет смысл использовать только в случае, если нет других способов сказать компилятору, какой индекс должен быть использован на основании информации о распределении данных в БД. А вы уверены, что такое распределение останется неизменным, одинаково для всех клиентов?
  • Существуют различные механизмы усиления брэкетинга, например перебор диапазонов возможных значений, использование временных таблиц, замена операторов <>, более гибкое использование конструкции (IF/THEN/ELSE)
  • OR – однозначно неудачно использовать внутри FIND, в случаях когда хотя бы одно из выражений разделенных OR неидексировано. Если все выражения внутри OR индексированы и их кол-во определено, то внутри FOR и QUERY использовать конструкции с OR целесообразно. Для того, чтобы избавится от OR выражений в WHERE можно использовать WORD-индексы, циклы.
  • Что лучше использовать один многокомпонентный индекс или несколько простых индексов? Ответ на этот вопрос зависит от конкретного приложения, но в случае использования всех компонентов многокомпонентного индекса доступ по нему гарантировано лучше, чем по нескольким простым индексам.
  • WORD-индексы включаются при использовании оператора CONTAINS (ни BEGINS, ни BY не используют WORD-индексы). При чем для оператора CONTAINS всегда требуется использование WORD-индекса.  Использование WORD индекса влияет на выполнение запроса в RUN-TIME. Так XREF может показывать использование нескольких индексов в запросе, тогда как в зависимости от выражения CONTAINS, реально может использоваться только один.
  • Для определения реально используемых индексов в RUN-TIME необходимо использовать параметр –zqil (Zecret Query Info Log). Статистика о запросах попадает в LG файл БД, поэтому должен использоваться только в процессе отладки. Особенную пользу приносит использование данного параметра в динамических запросах.
  • При компиляции с использованием XREF выражение WHOLE-INDEX не всегда означает обработку всех записей таблицы, например выражения FIND FIRST  и т.п. выдают в лог WHOLE-INDEX, но реально выполняются очень быстро.
  • При анализе XREF лога помимо WI на скорость приложения также влияет и сортировка выборок, в случае если выполняется сортировка в файле появляется слово SORT-ACCESS. Необходимо контролировать, что используемый  индекс выборки, совпадает с порядком сортировки.
  • Т.к. наличие индексов приводит к увеличению времени на обработку таблицы, то важным моментом является удаление неиспользуемых индексов. Для этого можно использовать XREF, для 9-ки наиболее правильным будет использование VST таблицы _indexstat, но при анализе использования индексов важным моментом является, что некоторые индексы могут использоваться для поддерэки уникальности.

INPUT-OUTPUT
 

  • PROGRESS использует стандартные устройства ввода/вывода, что позволяет использовать его для ввода/вывода на многочисленные устройства, используя перенаправление потоков, каналы I/O . Нет никаких проблем осуществлять I/O на ленточные устройства, сжимать информацию/сортировать информацию на лету.
  • Все стандартные операторы I/O могут осуществлять свои действия как со стандартной консолью, так и с файловыми устройствами.
  • Если не предполагается использование фреймового  ввода, то для увеличения скорости полезно использовать IMPORT. При использовании IMPORT не выполняются валидации, но тем не менее требования уникальности и обязательности выполняются.
  • Используйте символ «^» для игнорирования поля в файле.
  • Операторы IMPORT и SET передвигают указатель на следующую строку после выполнения.
  • Может быть полезным использование символа «.» для искусственного вызова события ENDKEY, стандартного события возбуждаемого PROGRESSом при достижении конца файла. Можно использовать «.» для импорта нескольких связанных таблиц из файла. «.» не влияет на IMPORT, если используется слово UNFORMATTED (м.б. это баг)
  • Для более удобной работы с файлами необходимо использовать системный виджет FILE-INFO (особенно в версии 9).
  • Для чтения файла, не содержащего разделителя (или содержащего специальные символы) и имеющий длину более 32К используются следующие приемы ввода:
       READKEY
       RAW-переменные
       MEMPTR-переменные
  • Для вывода в файл (устройство) специальных символов, используется конструкция PUT CONTROL. 
  • Для вывода в файл последовательности нулевых символов, предпочтительней использовать функцию NULL.
 
Чтение записей
 
  • Существует три вида областей видимости записи:
       Сильная
       Слабая
       Свободная ссылка.
  • Понятие область видимости связано с локировками записей, что является очень важным при разработке приложений. Область видимость задает видимость записи для компилятора.
  • Сильная область видимости задается конструкцией: DO FOR/REPEAT FOR. Попытка, обратиться к записи  вне блока, приведет к ошибке компиляции. Блок DO не имеет неявных транзакционных свойств в отличии от REPEAT поэтому поведение в двух случаях будет разным REPEAT освободит запись при выходе, тогда как DO нет.
  • Свободная ссылка позволяет ссылаться на запись в любом месте программы после того как встретилась одна из следующих конструкций: FIND, AVAILABLE, RECID, RUN PROC (BUFFER), DEFINE QUERY.
  • Слабая область видимости, запись видна внутри блока, а также может быть видна и за его пределами. Конструкции, определяющие слабую область видимости: FOR, REPEAT, DO PRESELECT.
  • RECID/ROWID в общем случае не требуют индекса для доступа к записи, исключение составляет использование WORD-индекса и когда область видимости уже использует индекс, то доступ по RECID внутри области видимости будет использовать индекс.
  • Как известно FOR сбрасывает последнюю обработанную запись при выходе из блока по END. Но из этого правила есть несколько исключений:
       LEAVE – преждевременный выход из блока
       BREAK BY – читает две записи
       FISRT/LAST – читает первую/последнюю запись.
  • FIND без опций FIRST/LAST (даже для уникальных индексов) и т.д. выполняет уникальный поиск, что приводит к двум запросам к БД, поэтому лучше стараться не использовать для увеличения производительности.
  • PRESELECT – формирует RESULT LIST, что приводит к некоторым задержкам при выполнении запроса, но последующее обращение к записям в запросе не вызывает задержек.
  • Опция BY для операторов FOR FIRST/LAST даст непредсказуемый результат поэтому правильно использовать FOR EACH/LEAVE.
  • Функция CAN-FIND выполняется на стороне клиента, поэтому необходимо избегать ее использования в WHERE выражениях, т.к. при этом теряется использование индекса.
  • Использование OPEN-QUERY с оператором DEFINE BROWSE делает доступной первую запись из выборки
  • Функция NUM-RESULST возвращает кол-во записей в RESULT LIST.
  • Оператор OPEN-QUERY не требует заранее определять выборку через DEFINE.
  • GET EXCLUSIVE-LOCK делает запись доступной, не смотря на то что локировка не может быть к ней применена.
  • Выполнение OPEN QUERY EXCLUSIVE не влияет на локировку записей до их чтения.
  • GET и FIND могут использовать совместно один и тот же буфер, но не один индексный курсор. Необходимо избегать совместного использования этих операторов по одному буферу, может привести к трудно разрешимым ошибкам.
  • REPOSITION – всегда использует RESULT LIST, не читает запись, указывает на место между записями. Может реально быть проблемой в случае использования в запросах без INDEXED-REPOSITION (с мультиндексами для версии 8).
 
Written by © Serguey Klimoff, 2003, Russia




Главная |  Статьи |  Книги |  Гостевая |  Ссылки |  От автора |  Download ProKb


������ ᠩ� pr Online ProKB Blogger Welcome to Russian Progress Users Group at Facebook Welcome to Russian Progress Users Group at LinkedIn
© 2009 - 2011 Все права на материалы, находящиеся на сайте www.openedge.ru, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах.
При любом использовании материалов сайта ссылка на источник обязательна.