Russian Qt Forum

Qt3. Postgres.
Задача: отображать большую таблицу (количество не важно, оптимизацией не будем тут заниматься, важно, что select выполняется порядка нескольких секунд). И так, нужно редактировать записи, удалять, добавлять, сортировать.
Вроде стандартный набор.
Заделал я через курсор и QDataTable это. Оказалось, что при рефреше таблице на клиента стягивается вся таблица, что есть громозко, но 1 раз при инициализации, и при сортировках это стерпеть можно, но как можно было эту задержку обойти при изменении таблицы? Наверняка кто-то как-то с подобной задачей сталкивался...

Заранее спасибо.

Функция refresh у QDataTable виртуальная. Переопредели ее и в ней принимай решение о refresh данных или иного. Больше вариантов при работе с QDataTable как то и в голову не приходит...

Переопределять ее, видимо, по-любому прийдется и пока видится 3 варианта: либо делать "select ... limit ...." для уменьшения выкачивания с сервера (но это замедляет скролинг), либо создать свой промежуточный буфер и при изменении таблицы синхронно менять и его (но это сложнее в реализации).
Ну и третий это вообще напрямую общаться с postgres и юзать курсор.
Вообще хотелось именно живой опыт узнать....

Обычно большие таблицы нет нужды возвращать, т.к. пользователь не может визуально обрабатывать сотни/тысячи строк. При больших объёмах пользователю в любом случае понадобятся фильтры, которые как раз позволят минимизировать число строк выборки.
Может стОит добавить уточняющие поля, например отображать данные за период "с" "по".

Это опытные пользователи могут эффективно использовать фильтры, а обычные захотят все и сразу...

Этот метод однозначно улучшит ситуацию и его использовать буду, но как дополнительный, т.к. хотелось бы сделать работу нормальной и при большом числе записей.

Честно говоря вопрос немного странный... Что значит много? 1млн записей? Это действительно много и не думаю, что пользователю это будет понятно и наглядно. По крайней мере если б у меня была таблица из хотя бы 10000 записей, я бы просто запарился искать нужную мне запись... Ну коли такая нетривиальная задача встала, то проще все измения таблицы кэшировать, а при её закрытии данные обновлять и тут без нового класса ну никак не обойтись!!!

Если я не ошибаюсь, то QDataTable использует курсор, т.е. на каждую ВИДИМУЮ на экране запись делается ОДИН запрос к базе. Лень исходники смотреть...

Я когда-то от QDataTable (QTable) отказался по другой причине - нужно было изменить высоту строки, а это требовало ручного изменения высоты КАЖДОЙ строки...

Честно говоря, я пока склоняюсь к перегрузки QSqlCursor, чтоб он работал по принцыпу "select ... limit ...", т.к. в этом случае будет тормозить только скроллинг, зато данные будут более оперативно и надежно в базу кидаться...
А то, что класс прийдется переписывать/перегружать это нормально, без этого никуда...

добавлено спустя 9 минут:

 
Таблица при отрисовке ячейки запрашивает инфу у курсора, а тот ее выгрибает из базы при инициализации:


Мысля: может можно как-то при изменении данных давать базе "insert/updete/delete" и соответствующие изменения производить в курсоровом буфере... Погляжу в исходниках...

Курсор на то и курсор, что он имеет текущую позицию и от нее прыгает и получает данные. Инфу из базы при инициализации он не выгребает (в смысле не накапливает), иначе все было бы очень долго и ресурсов требовало бы много. А вот пробегать по базе (таблице) вполне может...

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

Посмотрел исходники - QT данные не выгребает, это база данных. Т.е. полный рефреш все равно приведет к необходимости повторного выполнения запроса.
С какой базой работаешь? Может извратиться как-то получится...

Работаю с Postgres, но стараюсь использовать стандартные вещи, чтоб как можно безболезненней можно было сменить базу.
PS не нравится мне стиль, когда приложение увязано наглухо с чем-то...