Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2002.04.11;
Скачать: CL | DM;

Вниз

file of XXX   Найти похожие ветки 

 
LazorenkoX   (2002-03-29 13:03) [0]

Создаю я типизированный файл и делаю процедуры для его обработки, типа ReadRec(Index: LongInt); SaveRec(); и т.д. Но при создании процедуры типа DeleteRec(Index: LongInt); мне приходится создавать второй файл куда я копирую все Рексы кроме удаляемого затем заменяю старый файл вторым. Есть ли другой алгоритм удаления одной записи, со смещением всех следующих. Спасибо.


 
shane54 ©   (2002-03-29 13:09) [1]

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


 
Alx2 ©   (2002-03-29 13:16) [2]

Действительно, можно не удалять, а помечать. А потом их использовать для очередных SaveRec.


 
PVOzerski ©   (2002-03-29 13:23) [3]

Вообще-то вопрос можно разделить на 3.
1) Можно ли добраться до нужной записи, не перебирая все предшествоующие, а прямо
по смещению? - см. процедуру Seek и функцию FilePos.
2) Можно ли "укоротить" файл? - смотри процедуру Truncate - она "откусывает хвосты".
3) Можно ли "сдвинуть" записи, закрыв "дырку"-удаляемую запись? - вот тут дело сложнее.
Средств на уровне API я не припомню, да и быть бы их не должно, IMHO - это понизило бы
быстродействие доступа к файлам на уровне файловой системы. Здесь самое "лобовое"
решение - считывать очередную запись через read, откатываться на 2 позиции назад через
seek, писать через write, перескакивать через 1 позицию вперёд... - так до eof. А потом - truncate
на последнюю запись.

IMHO, в этой задаче лучше пользоваться всё-таки нетипизированными файлами с длиной записи 1.
Тогда "сдвинуть" записи, идущие за удаляемой можно будет практически за 1 приём - выделяем
динамический блок памяти, считываем туда одним blockred весь "хвост" и за один blockwrite вгоняем
его на нужное место.


 
shane54 ©   (2002-03-29 13:30) [4]

to PVOzerski

Не забывай, что мы не занем размер файла, с которым работает автор. При таких вопросах надо мыслить шире - может у него база на 1Tb :)


 
Alx2 ©   (2002-03-29 13:33) [5]

>PVOzerski © (29.03.02 13:23)
>IMHO, в этой задаче лучше пользоваться всё-таки
>нетипизированными файлами с длиной записи 1.
>Тогда "сдвинуть" записи, идущие за удаляемой можно будет
>практически за 1 приём - выделяем
>динамический блок памяти, считываем туда одним blockred
>весь "хвост" и за один blockwrite вгоняем
>его на нужное место.

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



Страницы: 1 вся ветка

Текущий архив: 2002.04.11;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.024 c
3-32681
Андре_
2002-03-20 08:59
2002.04.11
Indirect Synchrnization


1-32821
vlv
2002-03-28 17:40
2002.04.11
Создание компонентов


14-32955
BJValentine
2002-03-01 16:04
2002.04.11
Приколы ПО


3-32635
Dimonka
2002-03-19 12:40
2002.04.11
Вопрос по EhLib


1-32787
kvazar
2002-03-28 12:43
2002.04.11
CopyFile