|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Alexey Gradovtsev 2:5030/1247.7 03 Feb 2002 18:39:59
To : Vitus@ice.Ru
Subject : может регексп какой?
--------------------------------------------------------------------------------
vitus@ice.ru в письме к Alexey Gradovtsev от 02 февраля 2002 г., 11:40 писал:
AG>> А если требуется сделать выборку записей из БД, и чтобы потом много раз
AG>> не дергать базу, сохраняем выборку в файле, разделяя записи каким-нибудь
AG>> символом?
v> То данная задача называется _сериализацией_ структур данных, и для
v> ее решения существует, например, модуль Storable.
v> В некоторых простых случаях, я, правда, пользуюсь вышепроцитированным
А в каких, если не трудно?
v> приемом, но в качестве разделителя употребляю символ, который для этого
v> специально по стандарту предназначен. ASCII UNIT SEPARATOR называется.
0x1f?
AG>> Выборка может быть случайной, с требованием неповторения записей, и
AG>> cgi-скрипт использует ее не один раз, а каждый раз при запуске, до тех
AG>> пор, пока записи не кончатся. Тогда как быть?
v> Головой думать. Потому что в норме чтение из базы не медленнее чтения из
v> файла. а база еще и покэшировать может.
За storable спасибо, скачал. Вот только вопрос: ведь он все равно либо сохраняет
данные на диске (что делаю и я, причем, возможно, ненамного хуже, т.к. storable
использует банальный open(">$file")), либо замораживает их в переменной. И что
после этого делать с такой переменной? Передавать методом POST? Может, лучше все
же в файл?
AG>> Другой путь вижу - передавать через форму id записей, которые уже
AG>> использованы, и на каждой итерации выбирать из БД одну из оставшихся, но
AG>> ведь извращение?
v> Это не извращение. Если подумать что протокол HTTP stateless,
А как правильно переводится? ^^^^^^^^^
v> что у юзера может отвалиться коннект в любой момент, и не восстановиться
v> в течении нескольких часов, то извращением окажется таки хранение сессий
v> на сервере.
В моем случае это безразлично, т.к. сессии в норме сохраняются не так долго, до
нажатия кнопочки "Завершить". А вообще учту. Я так понимаю, это критично при
больших количествах сессий, когда накапливается толпа файлов? А как при большом
их количестве то, что дергать БД юзеры будут раз в 10 чаще?
Да, и еще. Если юзер по какой-то причине разорвал связь на несколько часов,
восстановить сессию ему, вероятнее всего, не удастся по продуманным причинам.
Так что эти сессии по любому уже невалидны.
03 февраля 2002 г. С наибестейшими регардсами,
*Alexey*.
... The most valuable truth are those most easily understood. Bartoli.
--- GoldED+/W32 snapshot-2001.02.24
* Origin: Три века без сна... (2:5030/1247.7)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
