вот если бы запись была бы фиксированной длины , то перезаписали бы мы часть файла и всё супер, а если перезаписываемая запись длинее старой то мы залезаем на следующую запись и пошло поехало ...
поэтому первая мысль а зачем ?
В разные файлы всё, и не волнует их длина , вот только как поведёт себя файловая система в таком случае ?

Если запись длиннее, то оставляем дырку, а запись вешаем на конец.
Раз в месяц делаем Vacuum

А файловая система... как тебе сказать... Я бы такое у себя не ставил 100%!

Вот и я засомневался ...потому и спросил...

мда раз в месяц сдавливать её ... мда может и неплохо...
только если мы ищем запись то находим её индекс "n" пропускаем "н" байтов читаем , если что в конец её ...

а что если выбирать запись надо по каким то параметрам (ну фамилия там)
то типо пробегаем по всем индексам ? смотрим запись , и смотрим совпадает запись с фильтром или нет?
только каждый раз когда мы смотрим данные по индексам нам надо пролизать (пропустить) файл данных до индекса "n" ?

Я бы делал так как предложил sergej.z,
едиственное что с файлами проще (а чем тупее тем надежнее) реализовать - все функции поиска по ключу(имени файла) берет на себя ОС

Что касается файловой системы - все будет нормально если файлы закрывать после добавления-редактирования не забудешь и питание раз в 10 минут лететь не будет - это же не мои фантазии - а из практики, у меня около 10 лет уж пашут без нареканий 2 такие штуки - одна под DOS, вторая по W98

Кстати решения КСС и Пейджлик по пейджинговым системам - на этом принципе - куча продаж была - собственно оттуда идею и взял в свое время

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

Иначе ищем в индексах. Для начала бинарным поиском можно воспользоваться.
Создаёшь ещё один файл, где указатели просортированы и ищешь например бинарным поиском.

PS:
Возми SQLite, раяо или поздно всё равно понадобятся все фичи

ОК допустим СКУЛит случаем копирайты не имеет сия фича , и проблем типа "Покупайте лицензию !"

Эта библиотека не только opensource, но и public domain. Означает - делайте с кодом что угодно, но не говорите потом, что это я так написал.

Написал её австралийский профессор, которому и так денег хватает. Она уже широко распространилась (например PHP5 имеет её уже встроенной)

Благая весть ! на сегодня и вообще спасибо !

Цитата(sergej @ 4.7.2005, 19:42)

Или, что проще, сделай функцию, которая бежит по индексу и переписыват файл - базу в другой файл, а старый стирает.

Так работает СУБД Аксесс и это хорошо при малых обьемах базы... когда же файл базы достигает 40 мегобайт, то время сжатия увеличивается до 10 минут. ЗЫ хотя Аксесс и не предназначен для таких обьемов

Цитата(En_t_end @ 4.7.2005, 17:14)

Так работает СУБД Аксесс и это хорошо при малых обьемах базы... когда же файл базы достигает 40 мегобайт, то время сжатия увеличивается до 10 минут. ЗЫ хотя Аксесс и не предназначен для таких обьемов

так работает любая СУББД просто некоторые стараются разбиение на файлы ограничить время переписки. вообще DELETE - очень проблематичная функция.

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

так есть ли смысл одним файлом то писать ?
единственный минус это быстродействие поиска файла (findfirst , findnext),но ведь это нужно сделать только один раз ,загружая список всех записей , да и файл можно заранее сделать с названиями , так то вообще быстро будет ?

Почему мне всё время кажется что я что то не учитываю ...

а насчёт переписи файла ... как то мне это кажется ещё более глупым нежели моё предложение .
средний размер базы будет 100-200 МБайт
каждый раз перезаписывать ? долговато будет... или раз в час ?

Цитата(Dubinsky @ 5.7.2005, 11:51)

а насчёт переписи файла ... как то мне это кажется ещё более глупым нежели моё предложение . средний размер базы будет 100-200 МБайт каждый раз перезаписывать ? долговато будет... или раз в час ?

Это зависит от того, как часто будут удалятся записи. Создай систему, которая считает "пустое место" в файле. Запускай функцию, когдо его будет слишком много.

А что, у тебя проблемы с SQLite? Дай пример своего кода, я помогу тебе её туда вставить.

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

пишем сначала пробный файл(бэкап с другим разрешением но тем же индексом) потом сам файл переписываем и затем стираем бэкап.

если на каком то этапе рубанёт ли[censored 9]ричество то:
1 не допишется бэкап
2 запишется бэкап но не запишется файл
3 не сотрётся бэкап

в любом случае информация целая только либо на бэкапе либо в самом файле, остаётся смотреть файл цел или нет и грузить соответствующий.
Добавлено @ 12:59
да пока проблем нет я не смотрел СКУлит ...

мне стало интересно почему так никто не делает ?

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

Цитата(Dubinsky @ 5.7.2005, 11:58)

мне стало интересно почему так никто не делает ?

Дык делают так почти в любой СУББД.

ПС:
Ещё тебе придётся реализовывать Begin work и Commit.

ладно а что мне надо от СКУлита ?? сорс ? или что они там предлагают ?