ru.cgi.perl

 
 - RU.CGI.PERL ------------------------------------------------------------------
 From : Comoderator of RU.CGI.PERL           2:5020/371.32  18 Feb 2001  16:15:03
 To : Rcmtu-net
 Subject : Moderatorial [+] (Re: Hа: Постраничный вывод)
 -------------------------------------------------------------------------------- 
 

 В твоём письме от Fri, 16 Feb 2001 11:05:57 +0300 написано:
 
 rnmnr> Да, с таблицей и мне понравилось, то есть ID запросов отсортированы в
 rnmnr> таблицу. Пришёл запрос, кодировка его в ID, сравнение с уже готовым,
 rnmnr> ежели нет, то на обработку, если есть, то пушем в пользователя. Потому
 rnmnr> что ежели в каждом запросе обрабатывается бешеное количество записей,
 rnmnr> кому это надо по 100раз одно и тоже отвечать, Даже в магазина вешают
 rnmnr> таблички, что бы одно и тоже не мусолить
 
 rnmnr> --
 rnmnr>     ==
 rnmnr> Ищу древний текстовый редактор PE-2 ( IBM's Personal Editor )
 rnmnr> Для ДОСа, дистрибутив ~ 70кбайт
 rnmnr> "Tarasov Sergej" <tarasov@pmi.lv> сообщил/сообщила в новостях следующее:
 rnmnr> news:2733094986@p2.f175.n5020.z2.ftn...
 >> Mon Feb 12 2001 20:59, Ruslan Bondarev wrote to Tarasov Sergej:
 RB>>     А теперь почитай свой рецепт:
 
 RB>> From: "Tarasov Sergej" <tarasov@pmi.lv>
 
 >> [skipped]
 
 RB>> === End of msg ===
 
 RB>>     А теперь скажи мне, что лучше - создавать для каждого запроса
 rnmnr> свой
 RB>> временный файл и затем заставлять одного пользователя с ним работать
 rnmnr> или
 RB>> создавать один файл на ВСЕХ пользователей, задавших этот запрос?
 
 >> Конечно, второе лучше. Hо гораздо сложнее. Как ты определишь, что этот
 >> запрос уже задавали и он еще в кеше? А так, если у каждого свой
 >> персональный кеш, не слишком сложно и почти так же эффективно.
 
 RB>> А если ты просто из одной базы строишь
 RB>> другую (причем переносишь ее в файл) и (наверное) при вызове
 rnmnr> пользуешься
 RB>> angle-operator ("<>"), а не seek'аешь по файлу с полями фиксированной
 RB>> длины - это, наверное, совсем не круто.
 RB>>     Я может и заблуждаюсь в своем мировоззрении, если что - поправь.
 rnmnr> (о;
 
 >> Hу, про файл я может погорячился, просто писал первое, что пришло в
 rnmnr> голову.
 >> Создать в той же базе таблицу и писать результаты поиска туда наверно
 >> проще и быстрее. Тем более, что база наверно не сразу эту информацию
 >> на диск скинет, и при запросе второй порции она еще может быть в памяти.
 >> Hо если говорить про сохдание временного файла, то на перле я бы сделал
 >> очень просто. В файле было бы просто N байт, по четыре (два или сколько
 >> угодно) байта на ID записей, которые были возвращены как результат
 >> запроса. Читаешь весь файл (или нужный кусок) и с помощью unpack делаешь
 >> массив чисел. И никаких angle-operator.
 
 RB>>     Да и вообще, ты что, Гугль свой пишешь, чтоль? Я же говорил, что
 rnmnr> при
 RB>> простом индексировании ключевого поля и не очень сложном пересечении
 rnmnr> мне
 RB>> сдвиг и LIMIT хватало выше крыши. Hе хватало бы - сказал бы директору
 RB>> проекта, чтобы он прикупил какой-нить Оракл или Информикс для этой
 RB>> задачи.
 
 >>  А ты что, пуп Земли? Исходный вопрос ты разве задавал? Если тебе хватает,
 >> я рад за тебя.
 
 Оверквотинг.
 -- 
 FIDO: Artem Chuprina, 2:5020/371.32, comoderator of RU.CGI.PERL
 Internet: Artem Chuprina <cmrcp@ran.pp.ru>, comoderator of fido7.ru.cgi.perl
 --- slrn/0.9.6.3-as (Linux)
  * Origin: AKA с подствольным плюсомётом (2:5020/371.32)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор