Удаление структуры из файла

[Stilet]

Нет ни одной причины держать в памяти дырки

В памяти - да согласен.

и ни одной причины сохранять дырки обратно в файл.

Еще как сохраняют.
Команды удаления являются креаторами дырок
Тем паче я говорил о том что СУБД не одобряют поджимания файлов. ИМХО только Сиквел из всех имеет более менее выскочный механизм дефрагментации.

[_Bers]

Сообщение от Stilet

В памяти - да согласен.

Еще как сохраняют.
Команды удаления являются креаторами дырок
Тем паче я говорил о том что СУБД не одобряют поджимания файлов. ИМХО только Сиквел из всех имеет более менее выскочный механизм дефрагментации.

ну вот смотри: грузишь с БД 5 строчек.

1 1 1 1 1

Потом две добавляешь:

1 1 1 1 1 1 1

И 3 удаляешь:

1 1 1 1

Ну и сохраняешься обратно на диске.

В следующий раз ты будешь грузить 4ре строки.

Вопрос к тебе: назови хоть одну причину, по которой БД стоит сохранять на диск дырки?

Ты действительно предлагаешь сохранять на диске: 1 1 0 1 1 1 1 ?

С таким подходом не удивительно иметь на выходе гигабайтный файл, в котором 600 метров - это дыры

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

[Stilet]

Вопрос к тебе: назови хоть одну причину, по которой БД стоит сохранять на диск дырки?

Вопросом на вопрос: Как по твоему, почему тяжелые СУБД стараются заранее зарезервировать место под чанк для базы достаточно большое, чтоб при работе с данными не нуждаться в дерганьи замедляющих работу методов дописывания в файл?
Почему АБД стараются не поджимать базу часто?

Пример: ВКонтакт не удаляет из своих БД никакие данные в ущерб месту, даже если пользователь их удалил (а на самом деле просто пометил как скрытые). А теперь ответь себе - почему?

[still_alive]

2Стремящийся

Можно ли физически удалить данные из файла?.

Это долго.

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

Можно тупо вести упорядоченный список свободных мест и записывать новые данные в минимальное по размеру место, где они помещаются. Если такого места нет, то склеить свободные места или перестроить файл. Короче, можно сделать упрощенную версию выделения динамической памяти.
А вот так, как предложил _Bers,

"файл, который на жестком диске" ты используешь один раз при старте, и один раз по окончании работы.

- лучше не делать. Если, конечно, у тебя более-менее серьезное приложение. Зато отображаемые в память файлы применять можно.

Да, согласен. Однако, у меня файл с одним именем используется во многих функциях программы, как тогда быть?

Передавать как параметр, а не использовать глобально или захардкожено.

2_Bers

Все что только возможно - берется в память. Нет ни одной причины держать в памяти дырки, и ни одной причины сохранять дырки обратно в файл.

СУБД, делающие мэппинг файлов, с тобой не согласны. Всем известная MongoDB тому яркий пример.

Вопрос к тебе: назови хоть одну причину, по которой БД стоит сохранять на диск дырки?

Можно назвать несколько распространенных причин, по которым размер БД может быть больше размера реальных данных:
1) preallocated files размером вплоть до 2 Гб - уменьшаем фрагментацию на диске и стоимость увеличения объема данных
2) padding на уровне коллекций - мало мешает, так как в освободившееся место мы вполне можем записать другой документ. И никаких дополнительных действий делать не нужно
3) padding на уровне документов - уменьшаем вероятность переноса документа в другое место (а следовательно не нужно будет обновлять все индексы этого документа) при обновлении (если размер документа перестал влезать в свободное пр-во)

[_Bers]

2still_alive, спасибо за интересный ответ