Я так же как и Вы склоняюсь к тому, что данное задание практически не реализовать. Черт ногу сломит. Выход можно найти, наверное еще, если использовать не целостный файл под все строки, а каждую строку складировать в файл. И иметь файл единый для атрибутов строк, допустим id<>имя файла строки но вот что если его также раздует, а его и раздует. Тоже не выход.
Полагаю необходимо находить какой-то иной алгоритм, допустим файл создается до определенного размера, затем после его заполнения создается второй, третий и так далее. но скрипт редактирования подобного хлама, будет неимоверно сложен и излишне, я бы сказал, негибок. Хотя это один из выходов.

Zmiuko, 
еще раз...

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

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

Допустим надо будет отредактировать строку. Получается мы пробегаем по файлам - ее находим. Тут все понятно.  Редактирование тоже понятно. Ну а вот удаление строки в середине - ставит меня в тупик. Это я про то, что если создавать не один большой файл, а множество с одинаковыми размерами - то есть не с одинаковыми, а записанными до указанного размера, естественно будут они отличаться и по размеру и по количеству строк. Получается - находим тот файл где строка, удаляем ее из него - и опля... надо переворотить всю базу - в каждом файле произвести смещение на -1 до указанного файла, в котором удалили строку. И опять тупик - если файлов, к примеру тысяча.

Я оговаривал суть задания. Необходимо разрешить чтение-удаление-редактирования строк или строки в файле большого размера (более ста тысяч объемных строк, файл более 300мб-1гб). В дебри лезу, что пытаюсь, может быть построить некоторую архитектуру разбиения файла и дальнейшей работы с ним.  Выхода другого не вижу.

Если Вам интересно, то такие задания дают в НГТУ - Новосибирском гос.техническом университете.  

Добавлено через 1 минуту и 16 секунд
Простите, решить необходимо на php используя стандартные функции. Естественно без применения СУБД. Так бы я давно файл засунул в мускул да работал там.

Добавлено через 1 минуту и 27 секунд
И вам бы голову не морочил 

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


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

Добавлено через 5 минут и 7 секунд
С базами данных на текстах, работал, знаю прекрасно какое это гомно и отсутствие всякой гибкости, лишь головная боль. Но вот дали мне такое задание. Что уж теперь.

Fortop, тут вся хитрость в том, что на самом-то деле в СУБД поиск по номеру строки мало того что почти не бывает нужен, а еще и идеологически вреден. Отсюда у нас растут другие средства. Побочным эффектом применения которых является отсутствие необходимости вырванивать файл. ;)

Мда. А подойти к преподавателю сложно?
Взять и уточнить, какой из 2х вариантов реализовывать.

А вот еще мысль пришла, читать файл, как предложено было ранее в своеобразный temp, а удаление-редактирование проводить посредством кеширования запросов. То есть удалили-отредактировали строку - ничего с фалом не делаем, а просто создаем новый, где указываем что удалили либо как отредактировали. Далее просто читаем файл для вывода заного, а в цикле чтения открываем второй файл и просто заменяем визуально все проводимые изменения. Выход?

Добавлено через 40 секунд


Там ответ простой: у Вас есть голова? Думайте!..

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

Ипатьев, ? Причем тут поиск записей?
Я все же пока еще верю, что ТС решает задачу именно "редактирования" файла, а не написания собственной СУБД.

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

Тогда выбираешь первый понравившийся и реализуешь его.
В чем сложность?

Стоп! Стоп! Не ерничать! никто вам не чего не засекречивал. Я имел ввиду заранее делить этот файл, дальше с кусками работать!

Добавлено через 47 секунд
Нужна была бы СУБД, я бы уж выход нашел... TXTSQL, к примеру взять во внимание.

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


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

Ипатьев и тебя благодарю, хоть ты сворливый и вредный, позже все-таки персонально для тебя создам тему о создании собственной СУБД!  

Добавлено через 10 минут и 24 секунды
А всеж вы правы в чем-то. Если производить дележку файла - то далее вся работа с ним похожа на работу СУБД. Вот только складывать обратно потом надо. Хотя можно просто циклом "подбирать куски".

Fortop, ну, мы ушли немного в сторону, к архитектуре БД.
О ней я и писал, о том, что вариант 2 не так уж и нужен в современных СУБД.

Что касается работы огромного файла, кстати, то сталкивался с проблемой работы с *.xls - php наотрез отказывался обрабатывать 9 мегабайтный файл.

Добавлено через 1 минуту и 16 секунд
И задание было схожее - произвести по нему поиск и выдать результат в виде *.xml . Ну как сами понимаете - интернет магазин.

Добавлено через 4 минуты и 45 секунд
Так вот проблема была в том, что содержимое *xls по-идее надо было в SQL-базу загрузить. Но Ваш покорный слуга делал шиворот-на-выворот, "на лету" обрабатывал *.xls в *.xml-вариант, а уж потом складывал его в базу. Ну и php, наотрез отказывался до конца обрабатывать этот *.xls .

Ипатьев,
Чтобы не было недоразумений -  вариант 2 это не ограничение длины записи, а структурирование информации, в том числе и при помощи дополнительной метаинформации (индексы, страницы, ссылки и т.д.)
Ограничение длины строки - это всего лишь палиатив предложенный в данном конкретном случае для ТС.


Если резать файл, то ничего складывать не надо.
1 строка - 1 файл.
Только следует понимать, что в данном случае мы работаем не с файлом, а массивом данных(информации) размещенным в множестве файлов.

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

Это сообщение отредактировал(а) Fortop - 5.3.2010, 16:27

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

Добавлено через 19 секунд
Имею ввиду про его создателей.