QTableView и БД с большой таблицей

[xilinx]

Версия QT 4.2.2, MySQL 5.027

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

[Sergey B.]

Да, если кто знает мне тоже интересно...
Такого пока не делал...
но зная Qt, предполагаю, что это как то красиво и гладко либо уже сделано, либо делается....

[bigirbis]

Народ! Присоединяюсь. Тоже такая задача встала. Весьма большая таблица, а ресурсы предполагаемой системы очень ограничены.
Если кто делал или просто имеет соображения...

[Ggg_old]

1. А зачем большую таблицу тянуть в грид вообще? Может лучше отдавать маленькую? Человек не машина - большой грид не осилит..
2. Если большой резалтсет получился сложной выборкой, то пока вы не заберете это все на клиента, строки, попавшие в выборку, будут на shared блокировке и могут помешать активным пишущим транзакциям (если сервер-блокировочник) или просто тупо держать размещенные под выбрку ресурсы на сервере..

[bigirbis]

А если в качестве БД используется SQLite? А простой резалтсет может составлять до 50 метров? А объем оперативы 64 метра? И уж свопиться лишний раз ну никак нельзя?
Цель вопроса - можно ли реализовать виртуальный резалтсет (простой селект с таблицы) так, чтобы он подгружался по мере необходимости либо сверху, либо снизу, и занимал фиксированный не очень большой объем памяти?

[Tonal]

Используй LIMIT и OFFSET в селекте.

[Alexandr Az]

Да не тянет она всю таблицу, не тянет.
Тянет вот стоки
#define QSQL_PREFETCH 255

Цель вопроса - можно ли реализовать виртуальный резалтсет (простой селект с таблицы) так, чтобы он подгружался по мере необходимости либо сверху, либо снизу, и занимал фиксированный не очень большой объем памяти?

Можно, чегож нельзя. Можно чтобы подгружал токи по одной записи, по мере продвижения по таблице. Но вот как реализовать окно - не знаю. Сверху ну никак догрузка не получится.... Как минимум нуно чтобы двунаправленые курсоры были у БД, либо организовывать своё кеширование, что глупо и сложно (имеется в виду кеширование со сбрасыванием на винт). А проще всего реализовывать свой буфер, т.к. кеширует записи QSqlQuery (читай QSqlResult, который реализован в кутешных дровах). Выход следующий - реализация своей модели со своим буфером, который юзает QSqlQuery с установленым setForwardOnly. Понятно, чем ниже по таблице лезем, тем больше у нас памяти захватывается.

[Jkc]

Самый простой путь как мне кажется это использовать в селекте лимит + в QDataTable сделать не прокрутку а перелистывание записей, скажем по 40. Принцип как на страницах в интренет. только там ещё используют цифры  1,2,3,4,5 >> . В данном случае цифры думаю лишнее, достаточно << >> и плюс едит в котором можно было бы задавать начальный номер записи и выводить туда последний номер записи.

[Alexandr Az]

Прикольно, представляю, лазим по каталогам  и жмём на такие кнопочки........ Модель сама по себе запрашивает метод canFetchMore() при достижении конца таблицы, зачем тогда стрелочки. Единственное что - так это модель действительно расчитана на кеширование записей и продвижение только вперёд. Это раз. 2 - не все БД поддерживают такие фитчи. На мускуле можно сделать  - на firebird - нет

[Jkc]

Прикольно, представляю, лазим по каталогам  и жмём на такие кнопочки........ Модель сама по себе запрашивает метод canFetchMore() при достижении конца таблицы, зачем тогда стрелочки. Единственное что - так это модель действительно расчитана на кеширование записей и продвижение только вперёд. Это раз. 2 - не все БД поддерживают такие фитчи. На мускуле можно сделать  - на firebird - нет

Ну во первых разница будет лиш в том что тут ты листаешь страницы как PageUp PageDown а не прокруткой в верх в низ.

Потом можно как листать записи скажем по 50 так и выбирать например от 2500той . Каждое перелистывание  или выборка это отдельный запрос где изменяем значения для LIMIT

В firebird по идее будет так  

Код:

SELECT FIRST 10 SKIP 20 column1, column2, column3 FROM foo

http://scott.yang.id.au/2004/01/limit-in-select-statements-in-firebird/
Конечно это не идеальный способ но по моему самый простой.

[nova]

Я вот одного не понимаю, зачем такое может понадобится пользователю( Вашей программы)?
Неужели вы полагаете что пользователь захочет, да и врядли физически сможет, просматривать такой объем информации?
Я не представляю себе задачи гдеб такое понадобилось.
В 99.99% случаев пользователь прекрасно знает что ему нужно в данный момент, и это "что" в 98% составдяет ОДНУ запись, в 2% случаев 10-100 записей, если у Вас получается больше то надо ставить вопрос не о том как кешировать/не кешировать зариси на клиентской машине, а о том что Вы не знаете о работе пользователя и какие функции поиска необходимы для него.
В оставшихся 0,01% случаев может производится выборка большего колличества строк но не для показа пользователю, а для (например) печати длинной простыни отчета, которую ни кто не будет читать, и слаживания этого отчета в архив. А для ентого идеально подходит QSqlQuery.

P.S. Хотя по нынешним временам 50 Мб таблицы енто ОЧЕНЬ маленькая таблица. Можно и на клиентскую маину в память загружать. В особо извращенных случаях

[bigirbis]

P.S. Хотя по нынешним временам 50 Мб таблицы енто ОЧЕНЬ маленькая таблица. Можно и на клиентскую маину в память загружать. В особо извращенных случаях

Имеется ввиду embedded...
Кстати, иногда и о старых машинах приходится задумываться (в редких случаях)

Я вот одного не понимаю, зачем такое может понадобится пользователю( Вашей программы)?
Неужели вы полагаете что пользователь захочет, да и врядли физически сможет, просматривать такой объем информации?

Имелась в виду динамическая фильтрация...
Но уже задумался о введении дополнительных ограничений на выборку.
Просто заказчик хотел бы видеть это именно так...

[Вячеслав]

Можно 5 копеек добавить ?
Динамическая фильтрация на embeded - это можно понять .... и даже сделать нормально... Но тащить 50 метров с сервера и фильтровать - как-то не кузяво - не проще в where засунуть фильтр ?

[bigirbis]

Но тащить 50 метров с сервера

Там SQLite будет локально...

[Вячеслав]

Гы ... а почему(SQLite) ? Нужна быстрая или нормальная бд ? Если второе - яб на птица посмотрел ... встроенного - глюки(фичи) есть, но не критичные )