su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Tolik Tentser                        2:5020/400     12 Apr 2003  14:13:30
 To : Serguei Tarassov
 Subject : Re: БД в тopгoвлe
 -------------------------------------------------------------------------------- 
 

 Hi, Serguei Tarassov!
 
 В чреве акулы, пойманной  Fri, 11 Apr 2003 22:03:57 +0000 (UTC), 
 дети капитана Гранта нашли письмо на тему 'Re: БД в тopгoвлe':
 
 > >> Изменение этого параметра приводит к необходимости
 > >>перепрограммирования логики поиска, которая и так непроста: "а если
 > >>приехало много записей, то следующий запрос не по тому же алгоритму к
 >>> серверу, а по другому, локально".
 > TT> Ой, это ты откуда такое придумал ?
 >Что тебя смутило ?
 
 То, что это по-моему куда-то в сторону.
 Или я тебя не понял
 
 > TT> Hу да, а на то, что пока клиент выбрал первично-отфильтрованные, а
 > TT> потом, прежде как ENTER нажать сходил пообедать - никто не
 > TT> закладывается. Hа то есть ссылочная целостность и код, отвечающий за
 > TT> обновление - сию (обычно довольно маловероятную) ситуацию - пущай они
 > TT> ловят
 >А зачем вероятность этой ситуации искусственно повышать ? Да и мала она
 >только на уровне справочников.
 
 Hу, а когда человек с клавиатуры вводит фильтр - то наверно
 вероятность, что он ушел чай пить никак не выше ? ;-)
 
 > TT> Hу, осталось (применительно к эхотагу) найти клиентский датасет HЕ
 > TT> УМЕЮЩИЙ этого делать. Задача непростая, хотя, наверно и реализуемая
 > TT> ;-)
 >Умеет, но это уже совсем другой use case. Усложнение стало быть.
 
 Hу так ведь всё равно уже уммет.
 
 > TT> Сервер много чего умеет делать, это еще не повод его грузить почем
 > TT> зря.
 >Клиент много чего умеет делать, это еще не повод его грузить почем зря.
 
 Производительность клиента - обычно некритичный ресурс.
 
 > TT> Hу да, и, чтобы отсортировать рекордсет будем тащить с сервера
 > TT> выборку. А клиентский Пентиум-черт-те-сколько, пущай простаивает.
 >Это совсем просто: сортировка в запросе вполне может проходить по полям,
 >часть из которых не присутствует в резалтсете (типичный пример -
 >динамический вывод на web-страницах ХХХ записей группами по УУ).
 >Да и рекордсет может и на _сервере_ приложений жить. Тонкого клиента еще
 >никто не отменял.
 >"Сервер много чего умеет делать, это еще не повод его грузить почем зря."
 >(с) ты :))
 
 Экий ты интересный ...
 
 Hу всяко понятно, что если на клиенте недостаточно данных для
 дальнейшей фильтрации/сортировки - то надо обращаться к серверу. Тут и
 обсуждать нечего. Вопрос - что делать, когда данных достаточно ?
 
 >Это еще большой вопрос, что лучше: тянуть с сервера большие резалтсеты (на
 >блокировочной СУБД почти гарантированно получишь table lock по чтению) 
 
 Hе пужай, всё не так страшно. Понятие "большой резалтсет на клиенте" -
 это сотни-тысячи записей, а страшный table lock ты получишь реально,
 попросив сотню-другую тысяч. Так что это вряд-ли.
 Bye ...
 Тенцер А.Л.
 tolik@katren.nsk.ru
 ICQ 15925834
 --- ifmail v.2.15dev4
  * Origin: AO Katren (2:5020/400)
 
 

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