| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
поиск "дыр" в ID [D7, dBase, FoxPro]
cp.Silver © (2006-09-15 21:24:00)Привет, мастера!
Чтобы не устанавливать сервер на машине пользователя и не использовать BDE, программа использует сл. механизм для доступа к БД dbase: ADO -> ODBC -> dbase.
Предполагаемый размер таблиц в БД: 30000-40000 записей. При этом будут постоянно выполняться операции DELETE/INSERT. Вся работа происходит на SQL-запросах без исп. TADOTable.
Как можно догадаться в поле ID таблиц будет очень много "дыр".
Вопрос следующий: какой существует самый надежный и быстрый способ найти "дыру" и вставить запись именно туда?
Метод перебора или даже бинарный поиск будут работать очень медленно. Чтобы не использовать поиск была идея при удалении записи помещать ее ID в отдельную таблицу и потом при вставке новой записи брать ID из этой таблицы. Но этот метод еализовать пока не получается.
Какие будут предложения, примеры (если есть)?
Anatoly Podgoretsky (2006-09-17 13:00:00) [41]Вообще то у dbase есть автоинкримент и уникальные индексы тоже.
Desdechado (2006-09-17 12:42:00) [42]> нет механизмов вроде автоинкремента для автоматизации и контроля работы с ID
Автоинкремента действительно нет, но это не повод искать дыры. Если бы автоинкремент был, ты бы ведь смирился с тем, что использовать дыру нельзя.
А контроль ID простой - уникальный индекс.
Anatoly Podgoretsky (2006-09-16 23:48:00) [43]dbase поддерживает до 10^20 знаков, итого если делать по 3000 операций в секунду, то потребуется 1 056 993 066 лет до переполнения.
cp.Silver (2006-09-16 23:38:00) [44]
Desdechado
> Потому как приложению должно быть все равно, какими механизмами
> обеспечивается ID и есть ли в нем дыры.
Так в том то и дело, что используется старая версия dbase, у которой в принципе нет механизмов вроде автоинкремента для автоматизации и контроля работы с ID. Поэтому и вопрос возник.
Johnmen (2006-09-16 22:16:00) [45]Ещё раз прошу любителей затыкать дыры обосновать своё желание. Без детского сада...
Desdechado (2006-09-16 18:31:00) [46]> удаление/вставка новых записей (скажем около 3000 операций за сеанс работы)
если еще учесть, что операций вставки наверно столько же, сколько и удалений, то за чеанс только 1.5 тыс новых записей.
> 2. Во многих случаях проектирование приложений для работы с БД без учета "дыр" считается плохим тоном
Я считаю (и я не одинок), что проектирование приложений, работающих с дырами, - это плохой тон. Потому как приложению должно быть все равно, какими механизмами обеспечивается ID и есть ли в нем дыры.
C@N (2006-09-16 17:37:00) [47]to [11]
а прикинь размерчик этой базы???)))
Shaman_ (2006-09-16 16:48:00) [48]> рано или поздно следующая операция вызовет переполнение максимального значения ID
Если я ничего не путаю, FoxPro позволяет создавать автоинкремент по integer полям. Максимальное значение 2147483647. На операциях с удалением/добавлением 3000 записей за сессию имеем запас разрядности ключа на 715827 сессий. 1 сессия в день, хватит на 1961 год непрерывной работы. Если же нагрузка будет выше, то стоит вообще подумать о переходе на другую СУБД. Многие СУБД позволяют строить автоинкрементный индекс по полям большей разрядности, тогда уж точно хватит на пару миллиардов лет
cp.Silver (2006-09-16 16:11:00) [49]
> Desdechado © (16.09.06 15:30) [9]
>
> SergP © (16.09.06 14:41) [8]
> Верю, но не вижу смысла. Примерчик бы...
>
Вот даже два примера:
1. Если в таблице постоянно происходит удаление/вставка новых записей (скажем около 3000 операций за сеанс работы), то если каждый раз вставлять запись в конец таблицы существует реальная угроза, что рано или поздно следующая операция вызовет переполнение максимального значения ID.
2. Во многих случаях проектирование приложений для работы с БД без учета "дыр" считается плохим тоном, но это зависит от задач, стоящих перед системой.
Desdechado (2006-09-16 15:30:00) [50]SergP © (16.09.06 14:41) [8]
Верю, но не вижу смысла. Примерчик бы...
SergP (2006-09-16 14:41:00) [51]> [5] Desdechado © (16.09.06 12:27)
> Какой смысл в поиске дыр?
Вы не поверите, но он бывает.... причем не единственный...
cp.Silver (2006-09-16 13:56:00) [52]2 Shaman_
Да, я действительно ТОРМОЗ, да еще какой!!!
Я совершенно забыл, что в SQL-запросе поддерживается арифметика (вроде select id+1...). И раньше я действительно думал сначала выбрать все записи, а потом используя ADOQuery.FieldValues[] искать дыры бинарным поиском... Согласен на все 100% - ТУПО...
2 SergP
Несколько секунд не сравнимо со временем перебора, согласись :) А твой запрос я проанализировал и его надо только немного приспособить под мои нужды. Все ОК, спасибо еще раз :)
Shaman_ (2006-09-16 12:44:00) [53]>2 Shaman_
>Тип ответа называется "лишь бы что-то написать"
Сам проанализируй что написал:
>Метод перебора или даже бинарный поиск будут работать очень медленно.
:
1. Это что это у тебя за теория насчет бинарного поска такая? С чего бы это такие дыры оказывали влияние на бинарный поиск? Для бинарного поиска вообще всеравно нарушена последовательность или нет, для него единственное условие это отсортированная последовательность чисел- и не имеет значения есть в ней разрывы или нет
2. Подскажи темному проггаммеру как ты в SQL запросах умудряешься использовать метод перебора? Или может выбираешь все подряд на клиента и там перебором ищешь нужную запись? =) Хочу тебя ратроить- в этом случае "дыры" тоже не имеют значения, если ты конечно не поставишь перед собой задачу написать код, скорость которого зависила бы от наличия дыр в индексе. Теоретический такой код можно написать =)
3. Индекс на то и нужен чтобы обеспечить абсолютную уникальность записи, и мудреж с ним ничем хорошим не обернется
Рекомендую не заниматься очень странными эксперементами а почитать литературу по основам БД
Desdechado (2006-09-16 12:27:00) [54]Какой смысл в поиске дыр?
SergP (2006-09-15 23:58:00) [55]> [3] cp.Silver © (15.09.06 23:31)
> 2 SergP
> Спасибо, вариант неплохой. Но у меня существуют опасения,
> что при огромном кол-ве записей dbase может повиснуть...
Ну я написал для примера... Но я аналогичным способом пользовался для нахождении "дыр" в оракловских таблицах. Ничего, оракл не повис. Ну запрос конечно выполнялся несколько секунд... Но у меня записей тоже было несколько десятков тысяч. Кроме того поле было текстовым (на преобразование к числовому тоже получается время тратилось), и индекса не было по этому полю.
Думаю если имеется индекс и поле числовое, то не должно особо тормозить либо виснуть.
cp.Silver (2006-09-15 23:31:00) [56]2 Shaman_
Тип ответа называется "лишь бы что-то написать"
2 SergP
Спасибо, вариант неплохой. Но у меня существуют опасения, что при огромном кол-ве записей dbase может повиснуть...
SergP (2006-09-15 23:02:00) [57]Например в упрощенном варианте можно типа так...:
select id+1 from table where id+1 not in (select id from table)
По идее такой запрос должен выдать список дыр (но не всех). но если "заделать" эти дыры и повторить запрос, то он выдаст новые дыры.
Shaman_ (2006-09-15 22:05:00) [58]Предложение не тормозить...
Извини за грубость
| |
Страницы: 