Russian Qt Forum

Подскажите, как лучше сделать:
Имеем СУБД, сервер, клиент.
Необходимо связать сервер и клиент, что бы на клиенте отображались табличные данные.
Пути решения которые приходят в голову:
1. Запрашивать с клиента и отправлять (к примеру через XML формат) все даные, т.е. всю выборку будет клиент на себя тягать
- тут конечно с трафиком проблемы будут
2. Запрашивать только отображаемые данные и делать кеш на 1-2 станицы для ускорения пролистывания страницы (через тот же XML данные передавать)
- тут встает вопрос о написании своей MVC с учетом логики хеширования записей (пока хз как это делается правильно)
3. Делать промежуточную БД на клиенте и синхронизировать с серверной допустим по ID и по времени модификации
- тут с GUI вроде как все понятно, и можно обойтись стандартным набором объектов
4. Сделать через сериализацию объектов (QSqlQueryModel  и подобных)
сериализацию по этой статье делать: http://habrahabr.ru/blogs/qt_software/83374/
- тут как и в 1-м пункте могут быть проблемы с трафиком.
Как быть?

а что, уже есть проблемы со скоростью пролистывания, проверено?

Предполагаю что могут быть, особенно при медленном интернет-канале

тут проблемы с траффиком предполагаются исключительно только из-за идиотского, простите, желания пихать всё и вся в хмл. возьмите хотя бы даже QDataStream "из коробки" - и он будет гораздо эффективнее, а функционально даже лучше (датастрим умеет работать с потоком и не хранит всё подряд в строках - можно запросто обернуть в аналог SqlRecord).
п.4 ссылку открывать лень
п.3 сразу отпадает, т.к. эффективную синхронизаю двух бд сторонними методами Вы не сделаете
п.2 если планируется масштабируемость, локальный кэш однозначно нужен; как реализовать - выбор за Вами
п.1 для "хэлло датабэйз" - сойдёт, для продакшена - станете заикой...

Проблемы с трафиком решаются (относительно) через сжатие, к примеру gzip-ом, отправляемого XML потока, но опять таки при больших объемах информации пока из таблицы сделаешь XML, пока сожмешь, пока отправишь, там распакуешь, распарсишь, вобщем времени уйдет много, работать медленно будет. С другой стороны XML довольно универсальный формат и позволит в дальнейшем без особого допила расширять возможности системы в разные стороны.
В этом весь и вопрос, что как бэ выбрать то не из чего пока. Т.е. я не представляю себе, допустим как обработать скрол пользователем таблицы... допустим на одну строку туда-сюда еще могу прикинуть алгоритм, а если он долго скролит и не по одной стоке а по нескольку сразу, или если PgDown нажмет или если сразу в конец захочет переместиться...

Читай про void QAbstractItemModel::fetchMore ( const QModelIndex & parent ) [virtual]

Допустим у меня отображаются 20 записей из 100 (на сервере), т.е. при показе таблицы пользователю я послал на сервер (не СУБД) запрос на выдачу первых 20.
Пользователь проскроллил 15 записей.
какой параметр у fetchMore мне расскажет, что я должен буду запросить с сервера еще 15 записей?
не запрашивать же 15 раз по одной....

fetchMore предоставляет вам свободу выбора параметра количества строк
fetchMore вызывается в случае отрисовки последней записи

http://doc.qt.nokia.com/4.7-snapshot/itemviews-fetchmore.html

на первый взгляд работает, если внимательно присмотреться, кривовато отрабатывает перемещение в конец или пролистывание страницы через PgDown.

Тут можно поступить проще.
1. Грузишь первые n записей.
2. Грузишь общее количество записей (которое возвращаешь на rowCount ()).
3. Если в data будет запрос записи, которой у тебя нет, загружаешь n записей рядом с нужной.
4. PROFIT!