|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 07 Apr 2003 18:36:05
To : Serguei Tarassov
Subject : Re: БД в тopгoвлe
--------------------------------------------------------------------------------
Hi, Serguei Tarassov!
В чреве акулы, пойманной Sun, 6 Apr 2003 10:53:27 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: БД в тopгoвлe':
> TT> Hапример, когда заведомо известно, что требуемая выборка есть
> TT> подмножество от уже имеющейся на клиенте. Характерный пример -
> TT> инкрементный поиск. По первой букве - запрашиваются данные,
> TT> начинающиеся на эту букву, по второй и следующим - нет смысла
> TT> перезапрашивать, ничего нового не будет, проще наложить фильтр на
> TT> клиенте. Естественно, по смене первой буквы - перезапросить надо.
>Существует также и много причин _не делать_ так.
>1. Ты закладываешься на то, что максимальное количество записей в резалтсете
>по первой букве будет не просто невелико (от десятков до пары сотен), но и
>примерно постоянным.
Hичуть. Интересует только ыерхняя граница. Если на Й придет мало слов
- да и фиг бы с ними
> Изменение этого параметра приводит к необходимости
>перепрограммирования логики поиска, которая и так непроста: "а если приехало
>много записей, то следующий запрос не по тому же алгоритму к серверу, а по
>другому, локально".
Ой, это ты откуда такое придумал ?
>2. Ты закладываешься на то, что во время фильтрации на клиенте данные не
>будут изменены (добавлены, удалены) другим пользователем. Если такое событие
>вероятно, то кроме фильтрации (с каждой фильтрацией вероятность выбрать уже
>неактуальные данные увеличивается) на клиенте придется хоть как-то
>синхронизировать состояние резалтсета с БД.
Hу да, а на то, что пока клиент выбрал первично-отфильтрованные, а
потом, прежде как ENTER нажать сходил пообедать - никто не
закладывается. Hа то есть ссылочная целостность и код, отвечающий за
обновление - сию (обычно довольно маловероятную) ситуацию - пущай они
ловят
>3. И самое неприятное, тебе приходится фактически дублировать на клиенте то,
>что сервер уже и так умеет хорошо делать. Т.е. клиентский датасет должен
>иметь свою примитивную подсистему фильтрации и её декларативного языка -
>подобия SQL.
Hу, осталось (применительно к эхотагу) найти клиентский датасет HЕ
УМЕЮЩИЙ этого делать. Задача непростая, хотя, наверно и реализуемая
;-)
Сервер много чего умеет делать, это еще не повод его грузить почем
зря.
>Подобные усложения должны быть чем-то оправданы и могут относится скорее к
>оптимизации в конкретных решениях, чем к общим случаям. То же самое касается
>и сортировки.
Hу да, и, чтобы отсортировать рекордсет будем тащить с сервера
выборку. А клиентский Пентиум-черт-те-сколько, пущай простаивает.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
