Благодарю, очень доброе решение. Правда иногда не вполне осуществимо, но это малое что из реально продуманных ответов на поставленую задачу.


Любой программист, даже далеко не веб, должен иметь понятие не столько об используемый командах в интерпретаторе (поскольку справку всегда можно прочесть), сколько в известных ошибках выдаваемыми используемым продуктом. Не думаю, что Вы не поняли о каких именно ошибках и проблемах шла речь. Если действительно в недоумении, то создайте файл в миллион строк и попробуйте вывести постранично строки (пять строк на страницу к примеру), дабы понять какая ошибка выведет сам апач, то думаю вам дополнительно необходимо к каждой строке применить строковые функции, либо к каждой, либо как к массиву. В первом случае себя покажет интерпретатор, а во втором сам апач. Думаю, с постановкой данной задачи справитесь.

Zmiuko, для записи  http://ua.php.net/manual/en/function.fwrite.php  

?? 

Это сообщение отредактировал(а) gcc - 4.3.2010, 08:36

На мой взгляд такая задача - бред в кубе. Я сделаю insert into .... а потом select * where ...  а потом ещё что нить и это займёт ~ 0.0002 секунды. Что за изобретения - мне непонятно.

Почему бред? Нормальный вопрос, пускай он и не используется.  При чем тут " insert into .... а потом select * where" ? Мы же про файл говорим.



Ну да, в курсе 

Zmiuko, один раз распарсить в бд и юзать на здоровье.

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

И тот же посоветованный sed здесь не исключение. Для редактирования файла он все так же читает его целиком поблочно и так же  целиком записывает в новый временный файл. 

Впрочем, что бы в этом убедится самим и наглядно увидеть алгоритм работы sed'а можно провести небольшой тест:

Создадим текстовый файл с 1 000 000 строк


И при помощи утилиты strace посмотрим как sed будет его редактировать:


Теперь смотрим, что у нас получилось :


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

И еще стоит заметить, что существует частный случай, когда все строки имеют фиксированную длину (т.е. когда длина любой строки остается неизменной). В этом случае вам не придется читать и перезаписывать весь файл. Алгоритмы, как это сделать, хорошо описаны в документации к PHP (ссылки вам привел Fortop во втором посте)

Это сообщение отредактировал(а) sTa1kEr - 4.3.2010, 15:49

Я хотел вчера спросить, но постеснялся 
Не подскажешь как это сделать на PHP? 

sTa1kEr, благодарю, вы очень популярно и качественно объяснили суть алгоритма. Одновременно и показали и рассказали. Благодарю. очевидно я был прав, что при редактированнии большого файла, необходимо производить изменение сегментарно и формировать кеш перезаписи, благодарю.

IgorIV, gif-анимация довольно сложна, прошу прощения что не могу уделить вам по ней времени, а вот округление углов - скрипт довольно прост:



Надеюсь, что модератор не рассердиться.

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

Zmiuko, в условии задания говорится что данные строки отсортированные или упорядоченные? если нет, то задание не реально простое, или не реально сложное (реляционная алгебра и т.д.  )...

вы говорите у вас файл более 1 Гига, но например, если таблица или база будет 50-150Гб, разве MySQL будет весь файл перезаписывать для того чтобы вставить, обновить или удалить?


Это сообщение отредактировал(а) gcc - 5.3.2010, 10:58

будет, конечно.
только не сразу.

Омг, а разве это вообще проблема?


И каким боком это должно быть реализовано? В случае если замещаемый блок неравноразмерен с новым - ничего не получится.

Zmiuko, рекомендую перечитать вот это

Тут предложены два единственно возможных варианта. Произвольный файл будет требовать полной перезаписи. Обойти это можно только лишь структурировав файл - например, ограничив длину строки 1000 символами ровно (даже если в ней лежит ровно 1на буква она будет занимать строку в 1000 байт). Большинство СУБД используют 2й вариант, естественно в более сложной форме.

а шелл бы был здесь как нельзя кстати 

Fortop, с появлением полей типа TEXT и varchar второй вариант уже не актуален 
Выравнивание ведь не единственное средство обеспечения произвольного доступа. хотя и наиболее доступное

Добавлено @ 15:29
LeoK, слово "здесь" к данной ситуации неприменимо.
Поскольку четкое позиционирование отсутствует. так что задача может быть как "здесь", так и "где-то там" или вообще "нигде".
Ближе всего к описанной задаче подходит "изобрести на коленке базу данных", о чем я уже давно и говорил, и к чему постепенно движется обсуждение. но в этом случае шелл, конечно, нужен, но гибче будет, все-таки, руками.

Это сообщение отредактировал(а) Ипатьев - 5.3.2010, 15:31

Разве? 

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

Но это именно структурирование хранимой информации.