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

видать вы мало бываете на этом форуме. можете сходить и почитать в раздел багов форума


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

Вы вообще понимаете, что предложенный NNaarreekk'ом метод для штатного механизма сессий увеличит количество дисковых операций минимум в 2 раза? Да за такое не компота, за такое работы лишают.


Со всем моим уважением к винграду, этот форум хороший тому пример. Только, имхо, здесь обратная ситуация, здешним девелоперам (если такие здесь вообще остались) не дают компота и как следствие...

Это сообщение отредактировал(а) MoLeX - 6.11.2009, 06:34

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



со всем моим уважением, я один раз вчера туканил перед чистым экраном /до того как он вообще вырубился/, когда же страница загрузилась - специально посмотрел время генерации - 74 секунды

/рк: уважение проявляется в том, что я по прежнему здесь пишу, не смотря на тормозюки/

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


ну какбы NLspieler уже писал об этом

bars80080, а можно все-таки твой пример поподробнее рассмотреть? Можно конкретнее, что за xml-ки и почему они должны парситься по запросу пользователя? Почему их изначально нельзя в бд запихнуть?

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



да пожалуйста.
есть такая компания "Аэрофлот", которой я совершенно не указ. обмен отчётностью с ней совершается посредством xml. вот теперь представьте, что находится в одной xml, согласно их формата:
одна xml - один агент, в ней неограниченное количество пачек за представленный период. пачки могут содержать до 50 транзакций каждая, притом что разные типы документов разделябтся по разным пачкам, так как формат у них разный. типов до 6 штук. в пределах каждой транзакции не менее 20 тэгов уходит на общее описалово и методы оплаты, в каждой транзакции до 4х купонов и до 8 такс, каждый купон ~ 12 тэгов, каждая такса ~ 8 тэгов, так что набегает приличный размер, а 300 кБ - это то с чем приходилось иметь дело

и вот у нас стало быть задача. валятся эти xml от субагентов, у нас проверяются и шлются дальше. и вот требуется значит содрать небольшой срез информации, в силу чего она распарсивается. вносить в БД целиком - не имеет смысла, у нас своя отчётность и всё что нужно уже в БД, для того чтобы хранить эти данные, пришлось бы организовать ещё лишних 7 таблиц, которыми всё равно бы никто никогда не пользовался. далее, полученная информация проходит по принципу визарда, где как раз и добавляются данные из БД, уточняются суммы по претензиям и прочая бухгалтерия. 
смысл мне на каждом этапе парсить одну и ту же xml-ку?
смысл мне захламлять базу лишний раз, если данными из неё мы пользуемся всего однажды. а через месяц все xml-ки сливаются в общий архив и удаляются с диска, ибо он тоже не резиновый

Как вы не поймете, что во втором случае придется точно так же парсить данные, только уже не по строкам, как в примере ТС'а, а разбирать сложную структуру переменной PHP.

И потом процессор, в отличии от жесткого диска, практически никогда не бывает узким местом на www серверах. 
К сведению один такт процессора исчисляется наносекундами (10^-9), время произвольного доступа на современном винте исчисляется миллисекундами (10^-3). Как бы быстро не крутилась головка винчестера, быстрее скорости света она не раскрутится  

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

Именно это я и имел ввиду под "хорошим" примером. 

Какую еще долю файла? Какие 100000 строк? Вы про что вообще? 
Речь о том, что приходится либо читать один файл один раз(!) или читать и писать те же данный в разные файлы N раз(!). Во втором случае обращений к диску будет в 2 * N раз больше (где N число пользователей с разными сессиями). И это все ради того, что бы сэкономить "пару" тактов (которые в в 10^6 быстрее любого обращения к диску) процессорного времени?

Это сообщение отредактировал(а) sTa1kEr - 5.11.2009, 13:00

Соглашусь, что в случае, когда информация из кривого файла требуется только один раз и только одному пользователю, то вариант с записью в сессию вполне применим.
Категорически не соглашусь с тем, что решение для этого исключительно редкого случая следует рекомендовать по умолчанию для всех вопросов, в которых упоминается чтение информации из файла.

Это сообщение отредактировал(а) Ипатьев - 5.11.2009, 13:08

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



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

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

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

Ваш пример никак не соответствует вопросу


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

Добавлено через 1 минуту и 8 секунд
Ну вот, опять Ипатьев раньше меня ответил  

ага, а сейчас мы будем настаивать на исключительность своего мнения? и, мол, никаких иных мнений супротив моего быть не может?
есть даже поговорка: сколько людей - столько мнений. неужели вам кажется, что все думают одинаково?


да ладно? гораздо больше соответствует, чем ваши предложения


да, именно такой пример я и привёл

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

Добавлено @ 19:22

Все просто, имхо, bars80080 использует аналогичный код предложенный NNaarreekk'ом и по этому воспринимает заявление о глупом совете на свой счет.

Это сообщение отредактировал(а) sTa1kEr - 5.11.2009, 19:24