|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 06 Apr 2003 14:53:27
To : Tolik Tentser
Subject : Re: БД в тopгoвлe
--------------------------------------------------------------------------------
Доброго дня, Tolik!
Hа письмо к Vladimir Pavlikov от Thu, 3 Apr 2003 14:53:31 +0000 (UTC):
>>"Очень любопытная мысль". Клиентские сортировки резалтсета действительно
>>встречаются нередко, ибо - какой смысл перезапрашивать те же данные
>>только для смены сортировки, но фильтрация??!
>>Сказать можно что угодно, вплоть до полной ерунды, но зачем?
TT> Hапример, когда заведомо известно, что требуемая выборка есть
TT> подмножество от уже имеющейся на клиенте. Характерный пример -
TT> инкрементный поиск. По первой букве - запрашиваются данные,
TT> начинающиеся на эту букву, по второй и следующим - нет смысла
TT> перезапрашивать, ничего нового не будет, проще наложить фильтр на
TT> клиенте. Естественно, по смене первой буквы - перезапросить надо.
Существует также и много причин _не делать_ так.
1. Ты закладываешься на то, что максимальное количество записей в резалтсете
по первой букве будет не просто невелико (от десятков до пары сотен), но и
примерно постоянным. Изменение этого параметра приводит к необходимости
перепрограммирования логики поиска, которая и так непроста: "а если приехало
много записей, то следующий запрос не по тому же алгоритму к серверу, а по
другому, локально".
2. Ты закладываешься на то, что во время фильтрации на клиенте данные не
будут изменены (добавлены, удалены) другим пользователем. Если такое событие
вероятно, то кроме фильтрации (с каждой фильтрацией вероятность выбрать уже
неактуальные данные увеличивается) на клиенте придется хоть как-то
синхронизировать состояние резалтсета с БД.
3. И самое неприятное, тебе приходится фактически дублировать на клиенте то,
что сервер уже и так умеет хорошо делать. Т.е. клиентский датасет должен
иметь свою примитивную подсистему фильтрации и её декларативного языка -
подобия SQL.
Подобные усложения должны быть чем-то оправданы и могут относится скорее к
оптимизации в конкретных решениях, чем к общим случаям. То же самое касается
и сортировки.
--
Сергей Тарасов
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
