Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

поиск "дыр" в ID [D7, dBase, FoxPro]

Страницы: < 1 2 3 >
cp.Silver © (2006-09-15 21:24:00)
Привет, мастера!
Чтобы не устанавливать сервер на машине пользователя и не использовать BDE, программа использует сл. механизм для доступа к БД dbase: ADO -> ODBC -> dbase.
Предполагаемый размер таблиц в БД: 30000-40000 записей. При этом будут постоянно выполняться операции DELETE/INSERT. Вся работа происходит на SQL-запросах без исп. TADOTable.
Как можно догадаться в поле ID таблиц будет очень много "дыр".

Вопрос следующий: какой существует самый надежный и быстрый способ найти "дыру" и вставить запись именно туда?

Метод перебора или даже бинарный поиск будут работать очень медленно. Чтобы не использовать поиск была идея при удалении записи помещать ее ID в отдельную таблицу и потом при вставке новой записи брать ID из этой таблицы. Но этот метод еализовать пока не получается.
Какие будут предложения, примеры (если есть)?

MikhailV (2006-09-18 16:59:00) [21]

> индексировать всю базу в несколько уровней и вносить изменения
> сразу в несколько файлв где один - главный сама база, а
> остальные - оглавление для этой базы по каждому полю...
> на каждый файл...
Что, простите?

Sergey13 (2006-09-18 16:57:00) [22]
> [36] Barloggg (18.09.06 16:53)

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

Barloggg (2006-09-18 16:53:00) [23]
а в чем проблема-то? в том что неохота весь файл перепахивать в поисках дыры?
я чего-то не понял?

а индексация спрашивается кому нужна?
вот и весь ответ.

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

это единственный вариант обеспечить идеальное быстродействие... при действительно больших объемах...

MikhailV (2006-09-18 16:44:00) [24]

> Если мы говорим про идентификатор, то такой проблемы просто
> не существует.

Безусловно.

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

Воистину правда, трудно не согласиться :))

MsGuns (2006-09-18 16:41:00) [25]
>MikhailV (18.09.06 16:10) [30]
>Но проблема-то есть.

"Разруха в головах" (с)

Johnmen (2006-09-18 16:35:00) [26]

> MikhailV (18.09.06 16:20) [32]
> Да я и не спорю. Просто, видимо, задача выбора
> "свободных" номеров из таблицы "занятых" извечна.

Если мы говорим про идентификатор, то такой проблемы просто не существует.
Если про что-то другое, то проблемы опять-таки нет. Всё зависит от предметной области и алгоритма...

MikhailV (2006-09-18 16:20:00) [27]

> Johnmen ©

Да я и не спорю. Просто, видимо, задача выбора "свободных" номеров из таблицы "занятых" извечна.

Johnmen (2006-09-18 16:13:00) [28]

> MikhailV (18.09.06 16:05) [28]
> ..Табельный номер ?

См. MsGuns © (18.09.06 10:34) [23] со слов "А ведь дело-то скорее всего в том..." и далее.

MikhailV (2006-09-18 16:10:00) [29]

> Глупости. Типичное символьное поле, тем паче повторяться
> может.

Но проблема-то есть.

Desdechado (2006-09-18 16:06:00) [30]
> Табельный номер ?
Глупости. Типичное символьное поле, тем паче повторяться может.

MikhailV (2006-09-18 16:05:00) [31]

> Johnmen © (16.09.06 22:16) [14]
> Ещё раз прошу любителей затыкать дыры обосновать своё желание.
> Без детского сада...

Табельный номер ?

Desdechado (2006-09-18 16:02:00) [32]
> она не удаляла записи, а быстренько ставила им пометки "стерто"
типичный механизм в DBF

> запустить процедуру "оптимизация" и тогда начинала шуршать винчестером
> компонуя новый файл базы без стертых записей
а это упаковка DBF

если, конечно, при упаковке не пересчитывались ключи для устранения дыр
а то бред выйдет, а не оптимизация

Barloggg (2006-09-18 15:59:00) [33]
действительно, дались вам эти дыры...

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

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

и все проблемы...
запускать такую процедуру раз в неделю/месяц и никаких проблем...

Плохиш (2006-09-18 10:40:00) [34]

> C@N © (16.09.06 17:37) [12]
> to [11]
> а прикинь размерчик этой базы?

Какое отношение наличие/отсутствие "дыр" имеет к размеру базы?

MsGuns (2006-09-18 10:35:00) [35]
Пардон,
>почему у его старшего брата номер БОЛЬШЕ, чем у него.

MsGuns (2006-09-18 10:34:00) [36]
Еще поражает стоеросовое упорство в преследовании галактической важности цели. Ведь десять человек уже твердят НАФИГА СДАЛИСЬ ТЕБЕ ЭТИ ДЫРЫ ? Ан нет. Все эти десятеро ничего не смыслят в космичности задумок, грандиозности цели..
А ведь дело-то скорее всего в том, что на счетчик хотят повесить несвойственные ему цели: что вроде номера чего-то там. Хотя назначение у него совершенно иное: всего-навсего однозначно и уникально идентифицировать запись в МНОЖЕСТВЕ записей, принаждежащих ОДНОЙ таблице.
Представляю себе картину:
чувак получает паспорт, смотрит в серию и номер и недоумевает почему у его старшего брата номер МЕНЬШЕ, чем у него.

Идиотизм какой-то, порожденный дремучим невежеством и упертым нежеланием попытаться понять то, что ему толкуют.

MsGuns (2006-09-18 10:27:00) [37]
>SergP © (15.09.06 23:02) [2]
>Например в упрощенном варианте можно типа так...:
>select id+1 from table where id+1 not in (select id from table)

"Простота хуже воровства" (с)

Не надо советовать глупости. К тому же глупости вредные.

Вся ветка напоминает фразу "Когда коту делать нечего, он яйца лижет"

Sergey13 (2006-09-18 09:10:00) [38]
> [0] cp.Silver © (15.09.06 21:24)
> Чтобы не устанавливать сервер на машине пользователя и не
> использовать BDE, программа использует сл. механизм для
> доступа к БД dbase: ADO -> ODBC -> dbase.
> Предполагаемый размер таблиц в БД: 30000-40000 записей.
> При этом будут постоянно выполняться операции DELETE/INSERT.
> Вся работа происходит на SQL-запросах без исп.

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

Anatoly Podgoretsky (2006-09-17 14:04:00) [39]
Появились в версии 7 и не только эти типы.

Desdechado (2006-09-17 13:23:00) [40]
Аnatoly Podgoretsky © (17.09.06 13:00) [18]
> Вообще то у dbase есть автоинкримент
В какой старойверсии он появился?

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »