Юристишко-выпускник

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

Я так понимаю, что Вы категорически против самой команды Pack в любом виде. Почему, собственно?

И еще, по-моему, должно быть очевидно, что "Rushmore-оптимизация" не есть синоним "ускорения". Тут более точно подойдет термин "как правило". Т.е. если запрос будет оптимизирован, то, как правило он будет выполняться быстрее.

Это правило. Но оно имеет исключения. О чем ясно и недвусмысленно написано в Help в справке по типам индексов

http://www.foxclub.ru/rhproject/project/html/fe911859-3235-4349-82c7-fa16a16d5527.htm

HRLP VFP9Visual FoxPro часто может создать битовую карту оптимизации Rushmore для бинарных индексов значитетельно быстрее, если число возвращаемых записей более, чем 3% от общего числа записей. Однако, если возвращаемое число записей менеее 3% от общего числа записей, то создание битовых карт оптимизации Rushmore является более медленным процессом . 3% барьер может уменьшаться по мере увеличения записей в таблице.

Замечание

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

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

Юристишко-выпускникВладимирМ Юристишко-выпускник

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

Я так понимаю, что Вы категорически против самой команды Pack в любом виде. Почему, собственно?

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

"ду ю андестенд ми?"

Юристишко-выпускник+ в некоторых разработках бывает привязка к номеру записи -
упаковал - получил проблему.
Т.е. Вы против по той причине, что у кого-то, где-то, разработка построена на использовании физического номера записи?

Юристишко-выпускникВладимирМТ.е. вывод простой, если записей, помеченных как удаленные, мало, то индекс по таким записям замедлит, а не ускорит выборку. А вот сколько именно записей будет "мало", а сколько "достаточно" определяется экспериментально.
еще раз

ну давай, показывай тормоза
Вы не верите тому, что написано в Help? Тогда бремя доказательства лежит на Вас. Продемонстрируйте ускорение, когда записей, помеченных как удаленные нет вообще или их количество существенно меньше общего количества записей. Для индекса типа Binary, в большинстве случаев, HELP говорит о пороге в 3%

прошелмимоВладимирМТогда бремя доказательства лежит на Вас.
Продемонстрируйте ускорение, когда записей, помеченных как удаленные нет вообще или их количество существенно меньше общего количества записей. Для индекса типа Binary, в большинстве случаев, HELP говорит о пороге в 3%


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


А разве я сказал не то же самое? Ну, хорошо, тогда "по буквам"

1. Индекс по Deleted() ускорит выполнение выборки, если общее количество записей, помеченных как удаленные, в среднем, более 3%.
2. Однако, индекс по Deleted() замедлит выполнение выборки, если общее количество записей, помеченных как удаленные, в среднем, менее 3% или вообще отсутствуют.

Это то, что утверждает HELP и с чем я согласен. Насколько я понимаю, Вы утверждаете, что факт наличия индекса ускорит выполнение выборки всегда и при любых условиях. Вот и докажите это свое утверждение. Т.е докажите, что второе положение - не верно.

На всякий случай уточню. Перед выполнением запросов FoxPro перзагружался?

Это я к тому, что Fox кеширует индексы. Как правило, первый раз после загрузки FoxPro запрос выполняется относительно медленно, зато потом "летает" именно в силу того, что индекс уже лежит в кеше и его не надо дополнительно скачивать.

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