Текущий архив: 2004.06.13;
Скачать: CL | DM;
ВнизОтображение больших объемов данных в Dataset Найти похожие ветки
← →
Vogul (2004-05-20 09:36) [0]Добрый день!
Необходимо дать пользователем возможность навигации по очень большому количеству записей. Выборка всех записей с сервера не выход, так как запрос естественно выполняется очень долго. Надо как-то организовать подгрузку данных с сервера, по мере необходимости. Например при скролле грида.
← →
GLFox (2004-05-20 09:39) [1]А DBGrid так и делает...
← →
Vogul (2004-05-20 09:53) [2]Не похоже.
На примере:
MaxRecords=30;
Время исполнения запроса ~ 0.3с
Использование памяти ~ 7 Мб
MaxRecords=0;
Время исполнения запроса ~ 3с
Использование памяти ~ 22 Мб
← →
Sergey13 © (2004-05-20 09:55) [3]А если заменить "навигацию" (т.е. вперед-назад) поиском по критериям? Может и проблема исчезнет?
← →
Ega23 © (2004-05-20 09:56) [4]Vogul (20.05.04 09:36)
А надо-ли их именно ВСЕ тащить? Может фильтровать? Конечно нужно оставлять пользователю возможность затащить ПОЛНУЮ выборку, но на своём опыте скажу, что пользователь делает это редко...
← →
Курдль © (2004-05-20 09:57) [5]Многие Датасэты выдают события onFetch..., которые можно разумно обрабатывать (это как вариант).
Но я считаю, что любой запрос надо готовить заранее, а иначе рано или поздно НД станет неподъемным.
Т.е. перед выбором субъекта нехило бы заставить юзера определиться, физик ему нужен, или юрик. А если юрик, то какой - кредитный или нет и т.д. :)
Кроме того, хороший выход - искать по умолчанию "используемых в последнее время".
← →
GLFox (2004-05-20 09:57) [6]Что касаемо запросов, то не стоит пренебрегать индексами. А что касаемо датасета, то нафига ему все данные из запроса, он фетчит только те которые можно посмотреть. Т.е., например, то что видно в гриде. Чтобы получить сразу и все есть такая фишка, т.е. метод FetchAll.
← →
Vogul (2004-05-20 10:09) [7]Так и фильтрация есть, но имеющиеся данные слабо структурированы, возможны только два или три уровня фильтрации, при том что объем их большой. У ADO компонентов события OnFetch нет.
← →
GLFox (2004-05-20 10:11) [8]А какой сервер то, вообще?
← →
Vlad © (2004-05-20 10:11) [9]
> Vogul (20.05.04 10:09) [7]
Курсор серверный поставь
← →
Vogul (2004-05-20 10:18) [10]С серверным курсором с памятью порядок, а вот с временем исполнения нет. Интересно, вот допустим MaxRecords тот же, как-то ведь ограничивает количество записей, только статично.
← →
Sergey13 © (2004-05-20 10:30) [11]2Vogul (20.05.04 10:09) [7]
Что за данные? Что ищут юзеры при просмотре "по очень большому количеству записей".
← →
kaif © (2004-05-20 12:04) [12]2 Vogul
Я где-то видел описание такой сетке...
К сожалению, не помню где. Возможно даже на www.ibase.ru была статья...
И эта сетка делала то, что ты хочешь.
Она выполняла запрос select count(*). Организовывала ползунок. Далее при навигации запрашивался тот "кусок" данных, который нужен. Все записи не фетчились, а только нужные. К примеру от 100-тысячной по 100-тысяче двадцатой. Эти записи сохранялись во внутреннем буфере. И так "по мере навигации" запси кусками набора считывались на клиент. Правда это была навигация по таблице, а не по результатам SQL-запроса. То есть предполагалось, что у таблицы имеется достаточно простой первичный ключ и SQL-запросы формаировались на ходу.
← →
Курдль © (2004-05-20 12:15) [13]
> Я где-то видел описание такой сетке...
TdxDBGrid (TdxDBTreeList) имеет опцию PartialLoad/LoadAllRecords
← →
Vlad © (2004-05-20 12:20) [14]
> kaif © (20.05.04 12:04) [12]
Только я не понимаю, что тут необычного, практически любые компоненты доступа имеют стандартную возможность фетчить либо все данные, либо по мере необходимости, в БДЕ можно даже конкретное число записей в пакете указать.
← →
Курдль © (2004-05-20 14:14) [15]
> Только я не понимаю, что тут необычного, практически любые
> компоненты доступа имеют стандартную возможность фетчить
> либо все данные, либо по мере необходимости
Только это сразу режет функциональность на порядок! Компоненты [13] теряют возможность сортировки, группировки, фильтрации, автопоиска и даже нормальной визуализации скроллинга.
← →
Vlad © (2004-05-20 14:17) [16]
> Курдль © (20.05.04 14:14) [15]
Какую фунциональность ? Сортировку-группировку-фильтрацию можно делать средствами SQL (лично я обычно так и делаю)
А уж если хочешь сортировку на клиенте, то по-любому придется фетчить все записи, какие есть
← →
Курдль © (2004-05-20 14:28) [17]
> Vlad © (20.05.04 14:17) [16]
> Какую фунциональность ? Сортировку-группировку-фильтрацию
> можно делать средствами SQL (лично я обычно так и делаю)
Вот ты, видать, не работал с Quantum Grid. Как ты сделаешь группировку "в дерево" простым переносом (drag-n-drop) заголовка группирующей колонки в "зону группировки" средствами SQL :)
← →
Vogul (2004-05-20 16:02) [18]Спасибо за разъяснения. Придется видимо организовывать внутренний кэш записей.
← →
Vlad © (2004-05-20 16:08) [19]
> Курдль © (20.05.04 14:28) [17]
Я работал с квантум-грид, и знаю, что он кэширует у себя весь набор данных. То есть получается фактически два набора данных, один DataSet, другой - собственный кэш грида. Это не всегда есть хорошо. Особенно при больших объемах.
Во вторых для подобной сортировки-группировки по-любому нужен полный фетч записей сразу.
А автору как раз оно не надо.
Страницы: 1 вся ветка
Текущий архив: 2004.06.13;
Скачать: CL | DM;
Память: 0.49 MB
Время: 0.039 c