Большой набор данных в гриде

← →
alsov © (2007-09-10 11:35) [0]

Приветствую, Мастера

Хотелось бы слышать ваше мнение по следующему вопросу.
Есть грид выводящий некий большой набор данных > 50000 записей. Есть возможность установить фильтр, а также осуществлять поиск по нему.
Проблема в том что грид грузиться достаточно долго (даже при использовании fetch). Первая пачка данных достаточно быстро отображается, но когда начинаешь скролить - висюки.

Плюс к этому пользователю не обязательно нужно видеть весь набор данных.

У меня есть несколько вариантов решения:
1. При открытии формы просить пользователя установить фильтр и если не установлен фильтр сообщение о том что будет долго работать.
2. По умолчанию устанавливать фильтр на то чтоб отображал скажем первые 500 записей.
3.Убрать скрол, выводить порциями например по 50 записей и сделать кнопки кнопки "<< Предыдущие 50" - "Следующие 50 >>"

Какой на ваш взгляд метод предпочтительней или есть еще варианты решения?

Использую Delphi+ODAC+Oracle+EhLib.

Заранее спасибо за отзывы.

← →
clickmaker © (2007-09-10 11:40) [1]

1 или 3
в 2 фильтр, который ты сочтешь нужным по умолчанию, может не устроить пользователя. Ему, например, надо 10 первых и 20 последних

← →
Ega23 © (2007-09-10 11:49) [2]

Ставить фильтры, причём много фильтров. фактически - по всем столбцам, что в гриде присутствуют.

Моя практика показывает, что пользователю редко больше 100 записей за раз нужны. Бывает, но редко. по крайней мере в тех системах, с которыми я сталкивался.

← →
sniknik © (2007-09-10 11:52) [3]

> Использую Delphi+ODAC+Oracle+EhLib.
использовать Delphi+ADO+MSSQL+DBGrid тогда выборка из 50 тыс покажется мелочью. (проверил на базе Northwind с многократно задублированными данными из Customers - полный запрос на 186368 зап. всего 2,5сек на пентиуме в 3 GHg с 1 гиг оперативки (секунду полюбоваться на "часики" ничего страшного))

хотя конечно, правильно предоставлять пользователю только то что ему нужно а не "скопом".

← →
Sergey13 © (2007-09-10 11:52) [4]

> [0] alsov © (10.09.07 11:35)
> есть еще варианты решения?

Заранее спросить юзера "Че те надо?" и выдавать запросом ТОЛЬКО то что попросит. Причем по возможности запретить юзеру отвечать в стиле "А фсе давай".

← →
sniknik © (2007-09-10 11:55) [5]

> Причем по возможности запретить юзеру отвечать в стиле "А фсе давай".
не, а вот запретов не надо. это раздражает, когда программа считает себя умнее чем тот кто пользуется...

← →
Ega23 © (2007-09-10 11:55) [6]

> (проверил на базе Northwind с многократно задублированными
> данными из Customers - полный запрос на 186368 зап. всего
> 2,5сек на пентиуме в 3 GHg с 1 гиг оперативки (секунду полюбоваться
> на "часики" ничего страшного)

Так он же пишет, что висюки на прорисовке грида (хотя сомнительно это как-то).

← →
Anatoly Podgoretsky © (2007-09-10 12:00) [7]

> Ega23 (10.09.2007 11:55:06) [6]

На все отвечать, мол сам виноват, тебя же придупреждали насчет головы. И повесить не часики а анимацию, что бы четко видел.

← →
sniknik © (2007-09-10 12:01) [8]

> Так он же пишет, что висюки на прорисовке грида (хотя сомнительно это как-то).
ну все как всегда, свои "ляпы" и незнание списывают на проблемы системы/используемого... а сам к примеру даже контролы не отключает при запросе... или там обработчиков понаставил рекурсивных, и т.д.

← →
Игорь Шевченко © (2007-09-10 12:04) [9]

← →
alsov © (2007-09-10 12:07) [10]

>
> Так он же пишет, что висюки на прорисовке грида (хотя сомнительно
> это как-то).

не на прорисовки грида а на фетче.
то есть ам запрос долго данные отдает и прорисовка тут не при чем.

← →
alsov © (2007-09-10 12:10) [11]

вобщем понятно
большинство за вызов окна фильтра перед запросом

← →
Anatoly Podgoretsky © (2007-09-10 12:10) [12]

> Игорь Шевченко © (10.09.07 12:04) [9]

Ну есть же и ниже оценки.

← →
Ega23 © (2007-09-10 12:11) [13]

> большинство за вызов окна фильтра перед запросом

Нет, не перед, а там-же. Внизу панель кладёшь - и 3-4 позиции сортировки с чек-боксами. Уже ускорит на порядок-2.

← →
sniknik © (2007-09-10 12:17) [14]

> большинство за вызов окна фильтра перед запросом
не совсем, про фильтр можно говорить потом, когда приведеш вывод даже большого количества (50 тыс), к приемлемому времени (должно быть меньше сек.)

да, правильно давать решать юзеру, чего и сколько ему надо, но тестить нужно именно на больших количествах и если у тебя такой мизер "тормозит" значит чего то в коде не то (или в генокоде если это тебе пофигу).

← →
isasa © (2007-09-10 12:17) [15]

Попробовать с серверным курсором ?

← →
sniknik © (2007-09-10 12:19) [16]

> Попробовать с серверным курсором ?
фетч это как раз признак серверного курсора... при локальном весь рекордсет передаётся сразу (может в используемых компонентах это и не так но сомневаюсь)

← →
isasa © (2007-09-10 12:20) [17]

alsov © (10.09.07 11:35)
Первая пачка данных достаточно быстро отображается, но когда начинаешь скролить - висюки.

Т.е. здесь, скорее, наоборот, с клиентским курсором?

← →
isasa © (2007-09-10 12:22) [18]

sniknik © (10.09.07 12:19) [16]
:)
Понял уже. С утра не проснулся.
Ну так открывать асинхронно, а пользователю, что-бы не скучно было, зайчиков там нарисовать, пока датасет на клиенте заполняется. Хотя, здесь тормоза могут дыть именно на гриде, а не на датасете.

← →
Desdechado © (2007-09-10 12:24) [19]

Если никак не удается формализовать предварительные ограничения (обычно при типичной свалке мусора в таблице), то вариант "следующие 50" вполне подходит. Иначе - только после задания ограничений читать.
Постфильтр использовать можно, но он не решает основной проблемы - длительности фетча.

> sniknik © (10.09.07 11:52) [3]
> использовать Delphi+ADO+MSSQL+DBGrid тогда выборка из 50 тыс покажется мелочью.
Дело не в скорости выборки, а в скорости доставки данных на клиента.

> Дело не в скорости выборки, а в скорости доставки данных на клиента.
???
в связке участвует DBGrid и время замерялось от посылки запроса до отображения данных в нем на клиенте, причём с клиентским курсором когда передаются всё. т.е. 2,5 сек включают все этапы без разделений на выполнение-передача-отображение.
(если сделать асинхронно то отображение будет раньше чем докачается все, но я примерно воспроизвёл описанную в [0] ситуацию с фетчем, т.е. если сравнивать то для одинаковых условий)

Удалено модератором

> [5] sniknik © (10.09.07 11:55)

Видимо программа реально умнее тебя, раз думаешь что тебе реально понадобятся когда-либо 5000 строк для просмотра.

sniknik © (10.09.07 12:34) [20]
Я не увидел ни у тебя, ни у автора описания тракта доставки данных. Есть большие подозрения, что каналы разные, а это может сильно сказываться на времени фетча.

homm © (10.09.07 12:46) [22]
вообще то я писал немного не так, я писал что не надо запретов для пользователя. особенно надуманных запретов, пусть даже для глупых с твоей точки зрения действий.

и кстати, ты наверное не в курсе, просмотр это не единственное что можно делать с данными.

Desdechado © (10.09.07 13:09) [23]
> Я не увидел ни у тебя
все на одной машине, в Server Network Utility первым стоит TCP/IP вторым Named Pipes, а что у она там себе выбирает х.з.
если разносить на разные (не в этот раз но проверялось) то время становится меньше, видать изза того что вместе сервер и клиент больше "напрягают" машину, а сеть в 100Мбит не является "слабым звеном".

> Есть большие подозрения
у меня гораздо большие подозрения, что ... см. [8].

> у меня гораздо большие подозрения, что ... см. [8].
Это само собой.
Просто sniknik © (10.09.07 11:52) [3] я понял, как то, что ты проводил тест только на MSSQL. Для адекватности надо бы проводить и другой, обсуждаемый.

> [24] sniknik © (10.09.07 13:20)
> вообще то я писал немного не так
Ага? [5] прочти, что ты закоментил.

и кстати, ты наверное не в курсе, просмотр это не единственное
> что можно делать с данными.
Простомотр и ввод новых данных, это единственное что должен делать пользователь. Для чего либо из этого нужно 5000 записей в одном гирде?

Не знаю как насчет других, но у меня для MS SQL влияние тракта ошеломляющее, когда они на одной машине, но скорость возрастает на два порядка, а по 1гб сети, скорость такая как в Интернете, только раза в два быстрее. Чтение ведется с NNTP сервера, база MS SQL 2000/2005 - памяти от 512 до 2 гб, проверка на разных машинах.

Большой набор данных в гриде Найти похожие ветки