что такое индексный файл

Отдельного упоминания заслуживает использование команды APPEND BLANK применительно к таблицам, по которым построены индексы типа Primary или Candidat.

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

Режим сортировки индексов (Collate)

Настройка SET COLLATE определяет режим сортировки символьных строк. Иными словами, какой символ надо поставить первым, а какой вторым, при упорядочивании.

По умолчанию, в FoxPro используется режим сортировки MACHINE. Это такой порядок сортировки, когда символы выстраиваются в соответствии с их ASCII-кодами. Чтобы понять что это означает (т.е. в каком порядке будут сортироваться символьные данные) посмотрите таблицу ASCII кодов. Это можно сделать так:

Обратите внимание, что сначала идут большие буквы и только потом маленькие. Кроме того, применительно к буквам русского алфавита, выпадает буква » ё » (ASCII-код 184) и » Ё » (ASCII-код 168). Именно в таком порядке и будут следовать символьные строки.

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

Как видите, буквы русского языка выстроились строго по алфавиту игнорируя разделение на большие и маленькие буквы и буква » Ё » заняла надлежащее ей место после » Е «. Можно заметить и другие отличия, но здесь я их рассматривать не буду.

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

Таким образом внутри одного индексного файла могут быть индексы созданные в разных режимах сортировки. Проверить режим сортировки в котором был создан индекс можно при помощи функции IDXCOLLATE()

Однако я бы не советовал на первых порах экспериментировать с SET COLLATE. Оставьте эту настройку в режиме по умолчанию, т.е. SET COLLATE TO ‘MACHINE’. Этому есть причины.

Метод половинного деления

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

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

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

А теперь посмотрим как поиск записи со значением 200 приблизительно будет выглядеть в индексе в случае использования метода половинного деления.

-) Вычисляется среднее арифметическое от граничных значений: (100+500)/2=300 и берется ближайшее значение из списка значений к вычисленному среднему. В данном случае это то же самое значение 300

-) Теперь смотрим в какой половине находится искомое значение 200. Оно находится в интервале от 100 до 300

-) Вычисляется среднее арифметическое этого нового интервала: (100+300)/2=200 и берется ближайшее значение из списка значений к вычисленному среднему. В данном случае это то же самое значение 200.

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

А теперь сравним, сколько шагов необходимо сделать в случае простого сканирования и в случае использования метода половинного деления

А в случае половинного деления количество операций определяется значением степени в которую следует возвести число 2, чтобы превысить миллирад (логарифм от миллиарда по основанию 2). Это число 30, поскольку 2**30=1,073,741,824. Т.е. в предельном случае для поиска значения в индексе потребуется не более 30 шагов

Выигрыш в производительности очевиден: миллирад против тридцати.

Использование индексов для отображения данных

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

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

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

Однако это вовсе не означает, что индексы для упорядочивания записей не используются. Дело в том, что любая таблица используемая в FoxPro может быть проиндексирована. Это относится как к обычным таблицам, так и к результатам выполнения команд Select-SQL, Local View и Remote View.

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

Некоторые особенности создания индексов для временных таблиц

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

Прежде всего, следует заметить, что индекс типа Candidat в «чистом» виде нас не устаивает по той причине, что в большинстве случаев задача контроля уникальности формулируется так: В таблице должны быть уникальны значения, если они удовлетворяют некоторым дополнительным условиям

Ну например, Вы хотите контролировать уникальность только среди записей не помеченных как удаленные.

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

Как следствие, получаем «раздувание» индексного файла на «лишний» индекс.

Кроме того, следует помнить, что проверка уникальности данных в индексах типа Candidat происходит сразу же при попытке внесения изменений, даже в буферизированных данных еще до сброса буфера. В то время, как триггер срабатывает только в момент сброса буфера. Эту особенность, следует учитывать при написании обработчика ошибок в приложении.

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

Есть еще одно соображение, не столь принципиального характера. В случае внесения изменений в правило контроля уникальности если речь идет об индексе, то потребуется удалить старый индекс и создать новый, а если речь идет о триггере, то надо будет просто заменить файлы базы данных (DBC, DCX, DCT) на новые (с новым триггером)

Название индексных тегов

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

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

Сколько и каких индексов надо создавать

Вопрос крайне неоднозначный и сильно зависит от конкретной задачи, однако некоторые рекомендации все-таки можно сделать.

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

Это были очевидные рекомендации связанные с поиском данных, поскольку и ключевое поле и внешние ключи будут использоваться очень часто и в самых разных условиях. Теперь рассмотим менее очевидные ситуации.

Индексы используются для ускорения получения выборок в так назваемой Rushmore-оптимизации. Что это такое и как оно работает я здесь объяснять не будут. С точки зрения создания индексов нас интересует следующая особенность работы Rushmore-оптимизации:

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

Следствием этой особенности работы является следующий вывод

Если объем информации (в байтах) НЕ удовлетворяющей условию выборки меньше, чем размер индекса (в байтах) по данному условию выборки, то в общем случае оптимизация приведет к замедлению выборки

В виде формулы это можно записать так. Оптимизация приведе к замедлению выборки если:

Объем информации НЕ удовлетворяющей условию

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

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

Частным случаем индекса по логическому выражению является индекс по выражению Deleted(). Этот индекс используется в случае настройки SET DELETED ON для того, чтобы оптимизировать выборку на предмет отсечения записей помеченных как удаленные. Как уже было сказано чуть выше, если количество удаленных записей относительно невелико, то данный индекс приведе не к ускорению, а к замедлению выборки.

Значительно сложнее определить необходимость прочих индексов. Да, есть некоторые правила, которые говорят, что если построить такой и такой индекс, то запрос будет оптимизирован. Даже есть функция SYS(3054) при помощи которой можно установить используется ли данный индекс при оптимизации или нет (да и то не всегда из-за несовершенства функции SYS(3054)). Но как было замечено ранее: оптимизация далеко не всегда приводит к ускорению получения выборки.

Поэтому фактически единственным критерием остается практика: если факт наличия индекса приводит к заметному (в разы) ускорению получения выборки, то его стоит создавать.

Но даже факт ускорения получения выборки не может являтся единственным критерием необходимости создания индекса. Еще одним не маловажным критерием является вопрос о том, насколько часто используется эта выборка.

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

Замечу еще, что индексы содержащие FOR-условия в оптимизации не участвуют

Рассмотрим следующий пример

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

Так вот, в данном случае произойдет модификация только одной записи. Механизм здесь следующий:

-) На первом шаге цикла SCAN указатель записей будет установлен на первую запись в соответсвии с главным индексом. Это запись со значением поля testID=1

-) По команде REPLACE значение поля TestID первой записи будет увеличено на 10 и примет значение 11. Немедленно произойдет модификация индексного файла и его перестроение. Теперь эта же самая запись оказывается не первой, а самой последней

-) На команде ENDSCAN будет предпринята попытка перейти на следующую запись, но в соответствии с новым значением индекса текущая запись уже последняя. Поэтому цикл будет завершен и запись со значением testID=2 так и останется не измененной.

Для исправления этой ситуации необходимо перед началом цикла сбросить главный индекс

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

Источник

• ← что такое седалищные мешки
• что такое перевод без открытия счета →