Технология работы с большими таблицами баз данных

[i9]

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

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

[Hordi]

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

[i9]

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

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

[nEoN]

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

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

[i9]

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

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

Может стОит добавить уточняющие поля, например отображать данные за период "с" "по".

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

[BaltikS]

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

[Hordi]

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

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

[i9]

Ну коли такая нетривиальная задача встала, то проще все измения таблицы кэшировать, а при её закрытии данные обновлять и тут без нового класса ну никак не обойтись!!!

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

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

 

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

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

Код:

bool QSqlCursor::exec( const QString & sql ){
    d->lastAt = QSql::BeforeFirst;
    QSqlQuery::exec( sql );
    return isActive();
}

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

[Hordi]

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

[i9]

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

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

[Hordi]

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

[i9]

С какой базой работаешь? Может извратиться как-то получится...

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