Форум: "Базы";
Текущий архив: 2002.08.29;
Скачать: [xml.tar.bz2];
Вниз
Время отклика Refresh растет при перемещении в конец датасета Найти похожие ветки
← →
Влад Утюмов (2002-08-08 18:52) [0]Я думал такая проблема только с однонаправленными датасетами. Попробовал с TIBTable - то же самое.
На firebird есть тестовая таблица ~80000 записей. Я просматриваю ее в гриде. Пока нахожусь в начале таблицы - Refresh работает моментально. Когда перемещаюсь в конец - возникает задержка секунд на пять. Такая же задержка происходит если из однонаправленного датасета фетчить всю таблицу за раз.
Делаю выводы: при перемещении по датасету увеличивается его буфер. Метод Refresh фетчит буфер _целиком_.
Вопрос: можно ли заставить делать refresh по-умному? чтобы извлекалось разнумное количество записей, не зависимо от того в какой части датасета находимся? Может другие компонеты доступа работают по-другому?
К слову, почему я считаю, что наблюдаемый эффект не есть рулез.
Я работал с 1С. Там Refresh происходит каждые пять секунд по умолчанию. Особых проблем не создает. В конце грида отклик такой же как и вначале. Это dBase в режиме файл-сервер. Почему же IB не может того же.
← →
Polevi (2002-08-08 18:58) [1]MIDAS позволяет сделать такое - немного переделаный провайдер и ClientDataset.RefreshRecord дадут нужный результат
← →
elv (2002-08-08 21:01) [2]Влад Утюмов
На firebird есть тестовая таблица ~80000 записей. Я просматриваю ее в гриде.
Боюсь прослыть не оригинальным, но зачем пользователю просматривать 80тыс записей. Если он потратит на просмотр каждой записи 1 сек., то потратит на это 22 часа. Так что в такой выборке смысла нет.
Делаю выводы: при перемещении по датасету увеличивается его буфер. Метод Refresh фетчит буфер _целиком_.
Да от "первой" до "текущей".
Вопрос: можно ли заставить делать refresh по-умному? чтобы извлекалось разнумное количество записей, не зависимо от того в какой части датасета находимся?
Сразу возникает вопрос - зачем? Зачем так часто рефрешить записи?У тебя такой интенсивный обмен с БД? Видимые данные могут устареть? Это настолько критично? И т.д. и т.п. и пр.
Может другие компонеты доступа работают по-другому?
Если не ошибаюсь, в FB можно селектом вытягивот N записей. Потом N следующих. Вытягивай хотя бы по 1000 записей.
В конце грида отклик такой же как и вначале. Это dBase в режиме файл-сервер. Почему же IB не может того же.
Потому что так задумано.
← →
Влад Утюмов (2002-08-09 10:38) [3]Polevi ©
MIDAS позволяет сделать такое - немного переделаный провайдер
RefreshRecord - это хорошая мысль.
А что в провайдере переделывать надо?
elv ©
но зачем пользователю просматривать 80тыс записей.
80 тыс. создают проблемы при локальном подключении. Полагаю, что по сети проблемы начнутся с меньшим количеством записей. Дело не в количестве. Просто удручает нерациональный трафик.
Еще заментил такой ньюанс: чтобы попасть в конец датасета (Ctrl + End на гриде) надо прочитать его весь. Может имеет смысл определять сразу два индекса: возрастающий и убывающий?
Если не сложно, поделитесь опытом, как в Delphi принято делать поиск. В 1С incremental search работает именно как поиск, т.е. он не сужает выборки, а перемещает курсор по таблице. Поэтому пользователь может легко просматривать гриды по 100 000 записей и больше. Похоже, что применяемый в MIDAS и IBDataset способ кэширования делает такой поиск неэффективным. Наверное все нормальные люди реализуют поиск как фильтр?
← →
elv (2002-08-09 10:54) [4]А вот смотри что я нашел.
http://www.ibase.ru/devinfo/ClientRefresh.htm
Обновление клиентских наборов данных в InterBase
Юрий Плотников, plotn@euro.ru
В своей первой статье по InterBase хочется остановиться на достаточно нетривиальном вопросе. Тем, кто переходит с локальных СУБД типа Paradox, DBISAM и т.д. возможно, как и мне не хватает автоматического и немедленного обновление данных в таблицах (на стороне клиента) при изменениях, производимыми одновременно несколькими пользователями.
Решение, которое приходит сразу кажется простым – реализовать события в триггерах, при получении которых набор данных обновляется. Также возможно запоминание курсора и возвращения его на место. Но… не гибко – если есть Calculated, Lookup поля, не самый маленький объем данных в таблице – не особо быстро выходит открытие при частых изменениях. Другое решение, предложенное мной сложнее, но, на мой взгляд, гораздо эффективнее. Суть в том, что при получении события обновлять набор данных у других клиентов посредством Delete, Edit, Append, но не генерируя SQL-запросов при этом.
....
← →
elv (2002-08-09 11:06) [5]Locate со смещением на первую удовлетворяющую условию.
Lookup без смещения.
SetKey/GoToKey со смещение
SetKey/GoToNearest поиск похожей со смещением
FindKey, FindNearest тоже поиск.
Ты сходи на www.ibase.ru.
← →
AlexSam (2002-08-09 11:53) [6]CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX index
ON table (col [, col …]);
Создай индексы ACS и DESC по полям, которые используются при сортировке. Используй TIBQuery и откажись от TIBTable (если используешь). Нормализуй базу данных.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.08.29;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.006 c