А с чего бы ему быстрее работать? В фоксе нет аналитических функций, так что только вот такая извращённая эмуляция - по сути 4 просмотра таблицы/индекса, а это и не может быть быстро... Зато оно работает и без индексов (на лету будут созданы оптимизатором), а "сканы" - не смогут.
С другой стороны искать ИМЕННО интервалы - ну я вообще не вижу никакого смысла в этом. А найти ПЕРВУЮ попавшуюся "дырку" - это в 2 раза меньше действий Правда тогда не обработать условие "размер дырки меньше/больше заданного"... А вообще я не вижу практического применения этой штуке. Ну, может, телефонные номера у ОпСоса, или регистрационные в ГИБДД - но я полагаю что там в базе ЕСТЬ запись про "свободный пропущенный номер" - просто она помечена как "свободная/утерянная/отобранная" и логика поиска будет другой.

Цитата:

Ну, может, телефонные номера у ОпСоса, или регистрационные в ГИБДД - но я полагаю что там в базе ЕСТЬ запись про "свободный пропущенный номер" - просто она помечена как "свободная/утерянная/отобранная" и логика поиска будет другой.

Ога. Примерно так.

Игорь, да, примерно, как у ОпСоС-ов, номера резервируются за регионами, и за конкретными агентами. Действительно, после этой "находилки" дырок есть постобработка, я пытаюсь соединить реально использованные номера с зарезервированными за конкретными агентами/регионами... Это я сделал первый шаг - извлечь из БД состояние дырок., далее пытаюсь наложить на нее (а может и на этапе начальной выборки) "зарезервированные" диапазоны номеров, диапазоны "именованные", пересекаются (бывает такое, это тоже надо обнаружить), и, главное, внятно показать состояние оператору. Вобщем, интересно разбирать такую задачу, которая не сразу решается, а может вообще не решается ).

Да, я знаю, эта тема (и не думаю, что это наиболее простая интерпретация этого способа поиска дырок) интересна только в конкретном приложении (жизни). Я не то что бы "знаю/помню" механику цифровых фильтров (с ЛЗ), но, вот взгляните, не я один такой:
forums.airbase.ru

of63
Да, я знаю, эта тема (и не думаю, что это наиболее простая интерпретация этого способа поиска дырок) интересна только в конкретном приложении (жизни). Я не то что бы "знаю/помню" механику цифровых фильтров (с ЛЗ), но, вот взгляните, не я один такой:
forums.airbase.ru

Способ, приведенный Равилем в принципе столетиями на фоксе работал без никаких проблем и со скоростью более чем.
Так что зачем искать чего-то "более красивого", если и так кода немного?
Проблема же у "других" в основном видимо связана с тем, что только в фоксе есть такая вещь как супер-индекс (запатентованный, а поэтому "вручную" едва ли воспроизводимый кем-то) создаваемый при этом через всего одну(!) команду. Плюс куча таких же хитрых команд конкретно для dbf, в частности SCAN - супер-команда, упрощающая и ускоряющая работу с ними.

Crispy
только в фоксе есть такая вещь как супер-индекс (запатентованный, а поэтому "вручную" едва ли воспроизводимый кем-то)

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

Crispy
создаваемый при этом через всего одну(!) команду.

Практически в любой реляционной СУБД индекс создаётся через "всего одну команду" - более того, некоторые индексы и вовсе создаются без "команд создания индекса".

Crispy
в частности SCAN - супер-команда, упрощающая и ускоряющая работу с ними.

Смешно
В "более других СУБД" данная конкретная задача решается вообще элементарно. Декларативно - без единой строки "процедурного" кода, чистым SQL-ем (естественно без подобных "нагромождений" как в моём примере), и более чем эффективно - при помощи аналитических функций.
"Позаписный просмотр" - он есть в процедурных расширениях больших СУБД, вот только нужен он весьма нечасто (т.к. он менее эффективен нежели обработка данных "всем скопом").
Нагромождения сканов вкупе с SEEK-ами - это как раз то что я просто не выношу в xBase языках (хотя порой приходится к этому прибегать - там где SQL движок фокса откровенно лажает). Это зачастую наиболее убогий вариант решения задачи (в части программирования) - но т.к. фоксовый оптимизатор достаточно слаб, а во всяких прочих клипперах вообще отсутствует как класс и приходится городить эти жуткие малоосмысленные огороды из "вложенных циклов". Кстати, это одна из причин по которой Си-подобные языки (в том числе и дотнет до появления LINQ) являются плохо приспособленными для обработки реляционных данных. То, что в высокоуровневом языке SQL пишется как SELECT MIN(поле1), SUM(поле2), поле3 FROM таблица1 INNER JOIN таблица2 ON ... WHERE ... GROUP BY ... "на сканах" (или для си-языков на for-циклах) превращается в форменную какашку
Ну да впрочем о вкусах не спорят

Igor Korolyov
...

Речь вообще-то шла не о СУБД.

Вообще-то если речь идёт об индексах, то речь идёт о СУБД. Нету ни в каких языках общего назначения никаких "индексов". И в фоксе индексы это часть движка СУБД, а вовсе не часть "языка" - построй индекс по массиву, или там по коллекции объектов на форме
Аналогично и в части команд процедурного манипулирования данными в курсорах - все эти SEEK/SCAN и иже с ними по сути часть фоксовой СУБД - потому и сравнивать надо не с каким-нить C# или там Java а именно что с PL/SQL, T-SQL и прочими языками встроенными в СУБД.

Вы уже вобще, я не об этом, а обсвойсве СКуЛ Языка в среде Фокс, знгая что он там эмулирован... а вы о чем?

А в других средах (Оракл, он чито, состоит из других машиных- опреарровах?ДНЕЛО в понятных разработчикамт предстравленичях...

Цитата:

далее пытаюсь наложить на нее (а может и на этапе начальной выборки) "зарезервированные" диапазоны номеров,

На Оракле есть интересная фишка, примерно так:

SELECT <полный_диапазон> FROM table1
MINUS
SELECT <диапазон_занятых_номеров> FROM table1 WHERE field_flag_active=1


А ежели отсортировать полученный список, ну или применить MIN() - вот кажется то, что нужно.

Вообще-то при наличии вспомогательной таблицы (которую зачастую полезно иметь) множества натуральных чисел от 1 до N это делается просто


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

Чтобы картина была полной приведу код на данных Игоря:




Исправлено 1 раз(а). Последнее : Dik, 18.01.14 12:15

Да, интуитивно чувствую, что надо иметь таблицу чисел (бесконечную иметь не получится, т.е до "верхнего предела", уже какое-то чувство неправильности...). Хотел(у) без такой таблицы (пока)

Про Оракл, Саша, да, опции MINUS не хватает, не знаю что она означает, (не OUTER INNER JOIN надеюсь), но что-то такое было-бы удобно... Как всегда, я написал что-то, всех устроило, я забыл (ну, потерял интерес, мотивацию улучшать...)

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

понял, вот так всегда бы ты ясно говорил