Здравствуйте.

Имеется текстовой файл с записями следующего типа:

текст|еще текст
другой текст|текст
еще текст|текст
 
и т.д.
файл считывается в массив с помощью функции file(), и потом рендомно работается с одной строкой - записью массива.

но сам файл весит 7,5мб и имеет более 150 000 записей.

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

fopen, fgets, fseek
но конечно изврат... по хорошему тут только БД поможет =)

А зачем тогда считывать весь файл? Может, ипользовать fgets с рандомным смещением относительно начала файла?

БД использовать пока нет возможности.

а вот то, что можно делать смещение в fgets  я не знал. спасибо  попробуем так 

Ну не совсем в fgets  .  Сначала задать смещение, а затем - вызвать fgets  

только скорее всего после fseek ты попадешь на центр какой нибудь строки, поэтому запускай 2-а раза fgets, и все будет ОК, кроме первой и последней строки в файле!

ну я понел. fseek-ом задаем смещение, потом юзаем fgets   


спасибо за идею  не споткнусь здесь.

При fopen файл все равно помещается в память целиком. Читаете вы его или нет.
Работа с большими файлами должна вестись через потоки. Сам не реализовывал, не было необходимости, но именно в таком случае можно считывать только то, что надо.

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

Это сообщение отредактировал(а) Mal Hack - 13.8.2007, 13:24

Вот ты подумал что сказал? Про поточи слышал? Знаешь что такое? fopen открывает не поток?

Diesel Draft, свой хамский тон уйми, пожалуйста. ;)


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

Я очень сильно сомневаюсь, что разработчки в фопен реализовали схему, т.к. на Си фопен 100% работает так, как описано в первом случае, да и тема тут была годичной давности, когда у кого-то из пользователей была проблема использования памяти с большим по объему файлом.

та я там смайл поставить забыл   

Вот ты здесь и не прав. Я помню когда появился РНР5 то в многих статях писало что теперь РНР будет поддерживать потоки, которые раньше только емулирувались.  
Можно проверить. У меня на роботе нет РНР интерпретатора. Поэтому если у тебя есть то помоги парню.
Просто загрузи припустим песню и посмотри на сколько изменились затраты памяти. 

Это не так. Да, fopen() не использует прямой доступ к файлу и не может позиционировать курсор в произвольное место файла, но он никогда не читает сразу весь файл в память. В PHP, конечно, можно позиционировать курсор, но методика несколько иная. При смещении курсора на $offset байт ему приходится прочитать эти $offset байт (что бы прочитать 1кб из середины файла размера 100мб, придется прочитать ~50мб). Т.о. fopen() практически не расходует память, но при использовании fseek() будет загружать винт.
Для работы с прямым доступом к диску можно использовать функции Direct IO Functions


Совершенно согласен, по хорошему fseek() вообще не должен работать в ASCII режиме. И если нету на то особой причины, то лучше всегда читать в бинарном режиме.

спасибо всем отписавшимся.

Mal Hack, можно дать линк с простейшим примером использования потоков при работе с файлами ?


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

Хм... Что-то я такого не помню, подкинь ссылку, посмотрю.


Если только в 5 это поменяли... Раньше такого точно не могло быть. 100%. Тестировал я большие файлы... Точно помню на 4 было так, как в сях.


Если поставить себя на место разработчиков, то мне кажется более лучший вариант, когда  fseek (в случае потоков) искал бы место нужной инфы на диске и давал ее не считывая то, что впереди... Это быстрее.
О такой схеме, я вообще не слышал, на таком низком уровне.

Antarn, sTa1kEr дал ссылку на DIO функции.

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