Главная страница
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.01 c
1-32774
Win32
2002-03-31 13:45
2002.04.11
Загрузку из Memo1


7-32996
Сергей Чурсин
2002-01-16 16:02
2002.04.11
Как убрать записи о неверных P&P устройствах ?


3-32661
AndDem
2002-03-18 16:31
2002.04.11
SQL-запрос. Проблема с пониманием возможностей SQL.


1-32762
SergeySh
2002-03-26 20:13
2002.04.11
ПОМОГИТЕ!


1-32804
Катерина
2002-04-01 09:26
2002.04.11
Директива INCLUDE