su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Serguei Tarassov                     2:5020/400     16 Apr 2003  02:05:22
 To : Nik Sestrin
 Subject : Re: БД в тopгoвлe
 -------------------------------------------------------------------------------- 
 

 
 Доброго дня, Nik!
 Hа письмо  к Serguei Tarassov от Tue, 15 Apr 2003 02:49:53 +0000 (UTC):
 
  NS> lol
  NS> особенно пикантно этот механизм будет выглядеть в вебе
 
 ГС (громкий смех :) )
 ты действительно думаешь, что фронт-енд как-то влияет на реализацию сего
 механизма ?
 
  NS> никто (в т.ч. и я) не отрицал необходимость делать это на уровне
  NS> сервера. некоторые (в т.ч. и ты) отрицали какую-либо возможность или
  NS> нужность делать это на клиенте.
 
 Ты что-то перепутал. Я привел доводы, почему это _не надо делать_ на
 клиенте.
 Если в твоей задаче они несущественны, то это означает, что... в твой задаче
 они несущественны.
 
  NS> делать на уровне клиента. Ответ был уже сформулирован: во всех случаях,
  NS> когда все необходимые данные уже есть на клиенте, фильтрация на сервере
  NS> - это еще один дополнительный запрос, лишняя нагрузка, время.
 
 и
 
  NS> увы, не отпал. так почему для ado.recordset.filter "если рекордсет в
  NS> middleware или даже на web-сервере, то такие операции там не к месту."
  NS> ?
 
 Твой собственный ответ на предыдущий вопрос тебя удовлетворяет ?
 Лишняя нагрузка на сервер приложений, необоснованное наличие больших
 резалтсетов в middleware (иначе, зачем фильтровать).
 И время тоже. Короткий дополнительный запрос к СУБД выполнится гораздо
 быстрее фильтрации или сортировки большого резалтсета на её клиенте. Потому
 что СУБД оптимизирована под такие задачи.
 
 --
 Сергей Тарасов
 Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
 --- ifmail v.2.15dev4
  * Origin: Talk.Mail.Ru (2:5020/400)
 
 

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