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

Кроме того, имейте в виду, что функцию Delete() в условии Where можно писать разве что для теста. Опять же, в реальных задачах фильтрация выполняется через SET DELETED ON. Впрочем, для теста это особой роли не играет

Мне кажется, Вы не поняли, что именно сравнивали. Основная идея прошелмимо заключается в следующем

Если использовать индекса по Deleted(), то он ускорит выполнение выборки настолько, насколько ускорится выполнение после команда PACK.

Вот этот тезис и был опровергнут.

BanditosЗЫ. Отсылка к началу: я тоже против постоянной упаковки таблиц. Упаковка нужна для тестирования, для решения проблем. Но в промышленной эксплуатации - вероятно, допущена ошибка в проектировке...
Упаковка происходит не "постоянно". Для этого создается специальный пункт меню или отдельная процедура. И какой-либо ответственный пользователь (если нет админа) периодически (раз в неделю, раз в месяц, раз в год) запускает эту процедуру

Отстутсвие подобной процедуры в промышленной эксплуатации и выполнение команды PACK "вручную" - вот это-то и есть "ошибка проектирования"

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

Banditos

Еще раз возвращаемся с того, с чего начали

У нас есть МНОГО записей помеченных как удаленные. Выборка тормозит. Необходимо ускорить выполнение выборки. Какие есть способы этого добиться?

1. Создать индекс по Deleted()
2. Выполнить команду PACK

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

BanditosКстати, я полностью согласен с прошелмимо, что если использовать индекс DELETED(), то выборка ускорится ПО УДАЛЕННЫМ ЗАПИСЯМ!!!!!!!!!!!!!!!!!!
Однако именно прошелмимо настаивает на том, что эта информация НЕ НУЖНА!

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

Юристишко-выпускникВладимирМОднако именно прошелмимо настаивает на том, что эта информация НЕ НУЖНА!

Теретик, Вам не кажется,
что Вы за меня многое домысливаете?
Во-первых, я могу и процитировать

Юристишко-выпускник3. "метка на удаление" в дбф и признак "удален" в интерфейсе - это есть разные вещи.
пользователь не знает и не должен, что есть какие-то дбф и какие-то служ.метки в нем.
для пользователя рисуют интерфейс и если необходимо уд-е и восст-е док-в,
то и придумывают каой-то признак, который никоем не зависит от служ.метки в дбф.
Во-вторых, я ведь с этим высказыванием и не спорю. Я с ним полностью согласен. Необходимость поиска именно записей помеченных как удаленные - довольно редкое явление.

Юристишко-выпускники ведете разговор в нужном Вам русле.
Разумеется. Я стараюсь, чтобы меня поняли. Поняли что именно я хочу сказать. Какую мысль донести. Поэтому так многословен и стараюсь не изъясняться "словесной жвачкой". Если я в чем-то ошибаюсь, сразу становится видно в чем. Не надо "домысливать"

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

не так-ли?
Почему это? Именно что реальной разработкой и занимаюсь. Точнее, сопровождением и "допиливанием" под "хотелки" пользователя существующего приложения.

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

Однако именно прошелмимо настаивает на том, что эта информация НЕ НУЖНА!


Вы, сударь - наглый лжец.

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

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

BanditosЕсли записи дальше не нужны - тогда ОДНОЗНАЧНО вариант 2 - выполнить команду PACK.

Но вот если у Вас каждый день набегает существенный объем таких записей, что у Вас начинает тормозить система из-за этого, и Вы просто вынуждены паковать таблицы - однозначно проблема в проектировке.

А если речь идет о профилактике, то раз в год нет проблем - можно и упаковать, и с архивировать. И упорядочить. И еще много чего.

Я не понял, а о чем тогда Вы спорите? Именно ЭТО мы с Dima T и объясняли с самого начала. Не вижу никаких противоречий с нашей позицией.

BanditosКстати, в моих проектах юзвери не могут удалить записи. Никогда и никак. У меня все эти записи просто переходят в другой статус. И когда база вырастает до неприемлемых размеров - я и архивирую, и пакую, и еще много чего. Но случается это весьма редко.
А делать сие даже раз в неделю - тьфу-тьфу... Мне просто очень жалко личного времени, чтобы делать сие даже раз в месяц....
Тоже согласен. Вполне здравый подход.

Юристишко-выпускник1. упаковка бывает неприменима по ряду причин.
Бывает. Я же не спорю. Но это, скорее, исключение, чем правило

Юристишко-выпускник2. есть способ создания бинарного индекса, который позволяет
оптимально работать с таблицами с удаленными записями.
Так что же Вы столько молчали! Давно бы привели пример и спор на этом завершился бы!

BanditosВладимирМпропущено...

Я не понял, а о чем тогда Вы спорите? Именно ЭТО мы с Dima T и объясняли с самого начала. Не вижу никаких противоречий с нашей позицией.

Хм, нет. Немного истории...

Раз:
Выделить удаленные записи в Grid
Два:
Выделить удаленные записи в Grid

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

1. Пользователь сам ничего физически не удаляет
2. Есть некая процедура, которая автоматически, с некоторой периодичностью, выполняет команду PACK

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

При этом нигде, никоим образом, прошелмимо даже не упоминал о периодичности команды PACK. Он возражал именно против нее как таковой. Аппелируя к тому, что индекс по Deleted() ее должен заменить

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=830283&msg=10283715

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

(...)

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