Перед каждым этапом теста фокс перезапускался.
Первый запуск не учитывал. Точнее запускал раз 15-20 подряд, время брал минимальное.
Общий порядок такой:
Код теста (test.prg):
Я думаю тест объективный получился

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

поэтому предусмотрев наличие индексов,
оптимизирующих выборки при наличии удал-х записей,
разработчик гарантирует стабильную работу ПО
вдали от себя.
Повторю свое мнение - отсутствие помеченных на удаление дает значительно большую производительность, чем хитрый индекс при большом количестве помеченных. Основные тормоза из-за чтения по сети:
Да, хитрый индекс немного уменьшает чтение данных, но полезные индексы все равно содержат ссылки на все записи независимо от пометки на удаления и это тянется на клиента. Размер индекса прямо-пропорционален количеству записей. Например индекс по полю типа int занимает 4 байта на 1 запись. Индекс типа BINARY 1 бит на запись.

Потом есть специфика чтения данных фоксом - чтение идет блоками по несколько записей подряд (filemon`ом можно увидеть), например в моем случае при размере записи 25 байт читаются блоки по 525. Т.е. помеченные все-равно будут читаться на клиента, если попадут в блок с нужными.

Непонятно почему команда PACK требует присутствия админа? Пересоздание индексов тоже админ должен делать?
Если есть проблемы с железом, то попортить таблицы можно и "легальными" операциями записи. Если с железом все нормально, то от PACKа проблем нет.
Если уж нужна супер-мега-устойчивость: бэкап перед паком, добавление контроля и восстановление из бэкапа в случае вылета в процессе пака.
Хотя эта процедура прописана качественно разработчиками фокса: создается временный файл, туда переносятся все непомеченные записи, удаляется исходный, временный переименовывается в DBF.
Лично у меня из-за PACKа никогда проблем не было. Во многих местах софт работает годами при ежедневном индексировании и упаковке без всякого админского вмешательства.

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

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

Юристишко-выпускникПовторю свое мнение -
Вобщем давай останемся каждый при своем мнении, т.к. предмет спора совсем не в индексе.

BanditosВедь вроде Ваше спор начался именно с необходимости упаковки таблицы. И именно упаковку таблицы уважаемый прошелмимо именно в данном случае предлагал заменить на индекс.
Вроде как об этом и спорили. Мой вывод:
Dima TПопроверял на других значениях nTovarId, получил на одном из значений результат с индексом быстрее на 0.002 сек.
Хотя если сделать PACK, то без индекса быстрее на 0.012 сек.

Вобщем мои выводы не в пользу индекса, согласен, он не мешает, но и не помогает.

BanditosВесьма вероятно, что я что-то не понимаю в Вашем споре. Но, имхо, выглядит так, что вы с Dima T подменяете понятия: начали разговор про необходимость упаковки таблицы, продолжили про то, что индекс при записях менее 3% мешает... Или Вы считаете, что наличие помеченных для удаления записей в количестве менее 3% - уже веское обоснование для периодической (постоянной?) упаковки таблицы?
Тут я ничего не понял. Как-то ты лихо рекомендации от МС "использовать хитрый индекс при более 3% помеченных на удаление" превратил в "веское обоснование для упаковки таблицы".

Чего-то ты так все вывернул, что для ответа весь наш спор заново надо повторить. Перечитай топик.

PS "прошелмимо" и "Юристишко-выпускник" это один и тот же человек.

Юристишко-выпускникИ Дима и Владмир это тоже один человек?
Разные
Юристишко-выпускникDima TВроде как об этом и спорили. Мой вывод:

Ваш вывод неверный.

Вы начали свои высеры с того, что наличие индекса - это какой-то
"тормоз".

В итоге Вы наловили микросекунд.
Ппц, сколько счастья что ты прав, всю ветку зафлудил.
Да, подтверждаю, ты ПРАВ в том что этот индекс не дает тормозов. Удовлетворен? Или справку на бумаге выдать?

BanditosКстати, меня сильно смущает Ваше тестирование.
Смущает - проведи свое. Выложи результат - обсудим.
BanditosЧто именно Вы хотели показать нам этим тестированием?
То что надо PACK регулярно делать и/или не плодить помеченные на удаление записи. Без помеченных на удаление быстрее выборки делаются чем с помеченными при наличии индекса.
BanditosА можно спросить: для чего вообще, по Вашему мнению, нужен этот самый бинарный индекс?
Я уже писал выше свое предположение: "Предложение создавать такие индексы со стороны МС появилось для желающих видеть полную оптимизацию по SYS(3054,11)"
Может они иногда ускоряют выборку как утверждает МС, но в моих тестах этого не произошло.
У меня выборка по той же таблице после PACK всегда происходила заметно быстрее.