|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Eugeney Putilin 2:5020/400 07 Apr 2003 12:24:03
To : Serguei Tarassov
Subject : Re: БД в тopгoвлe
--------------------------------------------------------------------------------
Sun Apr 06 2003 14:53, Serguei Tarassov wrote to Tolik Tentser:
ST> From: "Serguei Tarassov" <templar@arbinada.com>
ST> Доброго дня, Tolik!
ST> Hа письмо к Vladimir Pavlikov от Thu, 3 Apr 2003 14:53:31 +0000 (UTC):
>>> "Очень любопытная мысль". Клиентские сортировки резалтсета действительно
>>> встречаются нередко, ибо - какой смысл перезапрашивать те же данные
>>> только для смены сортировки, но фильтрация??!
>>> Сказать можно что угодно, вплоть до полной ерунды, но зачем?
TT>> Hапример, когда заведомо известно, что требуемая выборка есть
TT>> подмножество от уже имеющейся на клиенте. Характерный пример -
TT>> инкрементный поиск. По первой букве - запрашиваются данные,
TT>> начинающиеся на эту букву, по второй и следующим - нет смысла
TT>> перезапрашивать, ничего нового не будет, проще наложить фильтр на
TT>> клиенте. Естественно, по смене первой буквы - перезапросить надо.
ST> Существует также и много причин _не делать_ так.
ST> 1. Ты закладываешься на то, что максимальное количество записей в
ST> резалтсете по первой букве будет не просто невелико (от десятков до пары
ST> сотен), но и примерно постоянным. Изменение этого параметра приводит к
ST> необходимости перепрограммирования логики поиска, которая и так непроста:
ST> "а если приехало много записей, то следующий запрос не по тому же
ST> алгоритму к серверу, а по другому, локально".
ST> 2. Ты закладываешься на то, что во время фильтрации на клиенте данные не
ST> будут изменены (добавлены, удалены) другим пользователем. Если такое
ST> событие вероятно, то кроме фильтрации (с каждой фильтрацией вероятность
ST> выбрать уже неактуальные данные увеличивается) на клиенте придется хоть
ST> как-то синхронизировать состояние резалтсета с БД.
Это не обязательно может быть что в момент выборки 100-й записи в 20-й
произошли изменения, на это надо закладываться отдельно, или это остовляеться
до следующей выборки. Или это должно обновляеться на уровне событий. потом как
я понимаю поиск идет по первым буквам справочник, а это редко обновялемые вещи
(% измененых к общему объему)
ST> 3. И самое неприятное, тебе приходится фактически дублировать на клиенте
ST> то, что сервер уже и так умеет хорошо делать. Т.е. клиентский датасет
ST> должен
ST> иметь свою примитивную подсистему фильтрации и её декларативного языка -
ST> подобия SQL.
ST> Подобные усложения должны быть чем-то оправданы и могут относится скорее
ST> к оптимизации в конкретных решениях, чем к общим случаям. То же самое
ST> касается
ST> и сортировки.
Это может быть оправлданно повышение производительности, в случаее
сортировки на клиенте используеться его процессор, а не процессор сервера. В
варианте когда в системе несколько десятков или сотен клиентов это может дать
ощутимый прирост.
С уважением Путилин Евгений
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
