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

Юристишко-выпускникпри чем здесь УПАКОВКА?
какое отношение имеет создание индексов к УПАКОВКЕ таблиц?
почему нужно паковать все таблицы?
1. Обе операции требуют монопольного доступа.
2. PACK таблицы без индексов происходит быстро, индексы дольше создаются. Если нет помеченных то очень быстро (а они не каждый день появляются)
Поэтому я так делаю
Никаких вредных последствий от этого никогда не возникало.
Я так и не могу понять что в этом ненормального?
Кстати кроме воплей что это "ужас" других аргументов не было.

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

BanditosИ в неком ближайшем будущем, когда вы уже раз 20 упакуете таблицу, бухгалтер тетя Соня припрется к Вам в 17:27 и скажет:
- А чегой-то моего клиента (документа, платежки...) нигде нету? Я точно вводила. Затем редактировала, и снова вводила. Точно. А сегодня гляжу - нету нигде. А значит - Ваша программа глючит!

И фиг с два Вы отвертитесь, что это не так. И про то, был ли не был такой клиент - уже и узнать-то не получится...
Ну найду я помеченную на удаление платежку и что это изменит? Скажу была, но ее кто-то удалил. Тут же спросят кто? И что дальше? В итоге все-равно крайний разработчик.

Это кстати тот вопрос с которого топик начался. Если принципиально надо хранить все что ввели, то не надо встроенные средства пометки на удаление использовать. Тут я это и писал. И не только я

Юристишко-выпускникпользователям мануал пишем куда жать?
Зачем вообще куда-то жать? есть планировщик, который все делает. В мануал пишем как из планировщика запускать.

Sergey SizovDima T2. PACK таблицы без индексов происходит быстро, индексы дольше создаются.Дольше чего? Если нет помеченных то очень быстро"очень быстро" к чему относится? К PACK или к созданию индексов?
Вроде по-русски написал. Уточняю:
Индексы дольше создаются чем PACK таблицы без индексов
PACK таблицы без индексов происходит очень быстро если нет помеченных на удаление.

Sergey SizovА общее время команд меньше чем Pack с индексами? Почему рассматривается только время упаковки?
Некорректное сравнение. При наличии помеченных на удаление происходит переиндексация, при отсутствии помеченных переиндексации не происходит.
Время упаковки потому что обсуждаем упаковку.

Sergey Sizov, перечитай пожалуйста топик, кто за что агитирует, а то в меня моими же камнями...

Юристишко-выпускникесли софт на фокспро и используем родные таблицы,
то всегда пакуем и никак по-другому?
По-любому. Пакуем и точка.

Юристишко-выпускникесли софт на фокспро и используем таблицы,
то размер всех этих таблиц всегда в 4 млн.записей?

+ уж добью до конца - пусть кулинар чего-нить придумает еще про меня:
если софт на фокспро и используем родные таблицы,
то эти таблицы всегда в сети и т.д. ?
Тормоза начинают быть заметными при сетевом использовании, поэтому исходим из наихудшего варианта.
Размеры тестовых таблиц чтоб не в микросекундах сравнивать.

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

Тему необходимости использования PACK предлагаю закрыть на этом. Кому надо все аргументы за и против прочитают выше.

PS поизучал странные результаты "select count(*) from ..", пришел к выводу что таблица вообще не используется при наличии двух индексов. Стоит только добавить еще чего-нибудь внутрь селекта (например "select count(*), max(ID) from ..") так результаты сразу начинают быть близкими: Время без хитрого индекса (при помеченных) > Времени с хитрым индексом (при помеченных) > Время без хитрого индекса (после PACK)

Эту тему тоже предлагаю закрыть, т.к. каждый доказал то, что ему важнее.

Sergey SizovDima TSergey Sizov, перечитай пожалуйста топик, кто за что агитирует, а то в меня моими же камнями...Я его читал. И если я задаю вопросы, то значит в прочитанном я не нахожу достаточно прочной и однозначной причинно-следственной связи.
Я могу понять сравнение упаковки при наличии индексов и упаковки без индексов с последующим созданием индексов. В обоих случаях имеем одинаковые состояния системы и до операции, и после операции.
Я НЕ могу понять сравнение упаковки при наличии индексов и просто упаковки без индексов. До операции имеем индексы, после операции индексов не имеем.
Потом таки индексы безусловно делаются и состояние системы приходит в исходное. Но время на индексацию почему-то выкидываем из сравнения. Почему?
Спор был принципиально применять PACK или нет, я за то чтоб применять, оппоненты против. Аргументы выше.
Про скорость PACKа упомянул по причине что его присутствие незначительно замедлит.

Что касается этого кода:
то он не равнозначен этому:
Т.к. мне надо гарантированно пересоздать индексы. В первом случае индексы пересоздадутся только при наличии помеченных на удаление.

PS Давай тему PACKа закроем, я его использовал, использую и буду использовать. Особенности использования немного оффтопик.

Нашел альтернативу использованию PACK.
Задумка такая: заменяем в удаленных записях значение полей используемых в индексах на заведомо несуществующие.
Таким образом при выборке по индексу он даст только не помеченные на удаление записи.
PRIMARY KEY можно не трогать, т.к. он уникальный, а запросы с указанием значения помеченного на удаление - нарушение целостности.

Для тестов сделал repl in with 0 for deleted()
Потестил немного, результаты по убыванию скорости выполнения:
1. без хитрого индекса после PACKа
2. без хитрого индекса с 33% помеченных на удаление (без PACKа)
3. с хитрым индексом после PACKа
4. с хитрым индексом с 33% помеченных на удаление (без PACKа)

Реально все три варианта почти равны (разница по времени 1-2%)

Еще польза от такого подхода - быстрое нахождение помеченных записей (IndexSeek) и их восстановление (RECALL) для повторного использования. (По BINARY индексу IndexSeek() не работает), т.е. можно организовать работу с минимальным количеством помеченных совсем без PACKа раз уж столько претензий к нему.

Какие будут доводы против такого подхода?
Мне мысль понравилась, обязательно использую в каком-нибудь проекте, чтобы на реальной проге посмотреть.

PS Доводы про то что вдруг чего-то нужное случайно пометили просьба не приводить, исходим из того что если пометили - значит запись не нужна.