Stern87, 
а если попробовать так:
пришем в файл фиксированную длину строки, заведомо большую чем самая длинная
далее через seek бегаем по файлу

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

Сокращенно "прихоть" не получилось 
Можно. Программа уже n-й версии. И "структура" этих индекс-файлов не меняется уже очень долго. Люди пользуются разными версиями этой программы и они могут обменивать этими файлами, объединять их, или просто править в обыкновенном блокноте. Очень желательно, чтобы "структура" осталась такой же открытой и доступной.

Звучит неплохо. Вот я и спросил: если ли уже что-то готовое, потому что найти неполучается((( ??

Но это делает программу зависимой от Microsoft Office. А если программа работает на простеньком сервере в маленькой локальной сети? Ради её еще и Office ставить? Нет, спасибо за предложение, но альтернатива плохая.

А как узнать какая может попаться самый большой HTTP-адрес? В принципе, по RTF это 4096 (поправьте, если я не прав). Но а как же тогда будут сохраняться POST или куки всякие??


Можно даже упростить главный вопрос сформулировав так: что вы будете предпринимать, если окажется, что некогда ваш механизм оперирования с текстовым файлом (посредством TStringList) будет слишком медлительным и использовать слишком много ОЗУ (увеличить которое сможет далеко не каждый ваш потенциальный пользователь), и изменить структуру того текстового файла вы не можете?

Stern87, ты хочешь и рыбку съесть и вырезано цензурой.
Выиграешь в скорости - потеряешь в памяти и наоборот.

Да я уже скорость и не прошу. Мне просто нужно, чтобы ОЗУ не так кушало, а удобство было такое же как и работа с TStringList. Или, еще проще, навигация по строкам и добавление строки в конец. Вот и всё! Не так уж и много надо.

вместо tstringlist использовать массив строк, если сравнить: поиск по массиву будет происходить раз в 5-10 быстрее чем по tstringlist, т.к. если нужно быстрота, то объекты в твоем случае лучше отбросить, только лишь на вызов TStringList.Items[i] тратиться в 10 раз больше времени чем на тот же массив arr[i]... Так что загоняй строки в массив, и работай с ним ... естественно используй динамические массивы...

Это сообщение отредактировал(а) lukas - 18.2.2008, 17:35

Объясни в чем заключается удобство. Проще будет думать.

Добавлено через 10 минут и 46 секунд

Append? 


А вот это я не понял

Писал уже - можно легко добавить строку в конец, а также, можно обратиться к любой строчке.

Он открывает текстовый файл для записи строк в конец. Читать им строки открытого файла, кажется, нельзя.

Да, но что мешает Reset - прочитать - закрыть, Append - записать - закрыть. 
Или я что-то не понимаю?

грузить 200 метров текста в память??? я бы тоже БД использовал

Добавлено через 7 минут и 49 секунд

акцесс тормознутый

Добавлено через 9 минут и 46 секунд

firebird

При таких жестких условиях я бы FileStream использовал. При более мягких:

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

Скорее не целиком, а блоками...

Stern87
Запись текстового файла (то бишь Ваша строка) состоит из двух частей: ключ поиска - это URL-адрес поста, информация записи - текст поста юзера. Длина ключа поиска и длина информационной части записи являются переменными. Правильно понимаю условие задачи?

Мне кажется, что GreenPC предлагает хорошую идею: использовать Seek.

Только надо немного дополнить:
- надо преобразовать ключ поиска в 16-ный хэш, н-р, использовать SHA-1, который выдает 20 байтный хэш;
- в памяти хранить этот хэш и Integer-смещение записи от начала текстового файла; 
- итого: длина элемента динамического массива равна 24 байтам.

Тогда требование к памяти должно снизиться и Вы можете делать поиск хэша для ключа, введенного  юзером. 

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



Это сообщение отредактировал(а) mutex - 19.2.2008, 03:42

mutex,