QT: клиент-серверное приложение с SQLite

QTableView работает с моделью

сериализовать на сервере, десериализовать на клиенте.

т.е. лучше все-таки модель туда-сюда гонять?

не уверен на счет лучше, по моему это проще всего.

ТС я работаю в примерно таком же направлении, если есть желание пообщаться подробнее в тему твоего сабжа стучись в гуглочат, адрес в моем профиле.

Недавно обсуждалось.

замени SQLite на PostgreSQL

замени SQLite на PostgreSQL

успеется же

Уж е писали, что QT != Qt.

я тоже подобное пишу. Только выбрал путь - гонять туда-сюда json.

поболтаем в гуглочате на эту тему?

да, легко.

Клиент посылает запросы серверу, который читает данные из SQLite базы

А нахрена, я извиняюсь, вам прослойка в виде дополнительного сервера? Нельзя ли клиенту сразу обращаться к базе, которая и есть сервер или ваш велосервер делает еще какую-то работу?

мой гуглочат в профиле. стучись.

клиент-сервер позволит реализовать интересные вещи которые невозможны при прямом подключении к базе.

такие как балансировка, система гибкого доступа минуя правила доступа внутри базы итп итд.

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

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

нет ничего сложного в компиляции плагинов под тот же Postgres

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

У меня складывается впечатление, что ты диванный теоретик. =)

такие как балансировка, система гибкого доступа минуя правила доступа внутри базы итп итд

Че? Интересно, как это oracle, ibm и, о боже, microsoft обходятся без велосипедных серверов для балансировки и разграничения доступа к базе.

Я пробовал компилить драйвер MySQL по инструкциям, но ничего не вышло

Ага, навелосипедить свой собственный сетевой интерфейс к sqlite, конечно проще, чем собрать готовый драйвер - да вы упоролись.

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

Ну так и нечего тут лепить отмазки про гибкий доступ. Осильте компиляцию драйвера под любую сетевую СУБД. Вот вам для примера уже собранный драйвер для firebird http://rghost.ru/45200639

Че? Интересно, как это oracle, ibm и, о боже, microsoft обходятся без велосипедных серверов для балансировки и разграничения доступа к базе.

еще один диванный теоретик Oracle даже в глаза не видевший?

Есть ведь и гибридные системы, не единым ораклом и МС живем.

еще один диванный теоретик Oracle даже в глаза не видевший?

Давай-ка лучше пример, что такое нужно делать для доступа к базе, чего нет в продуктах oracle или других сторонних решениях, ради чего нужно велосипедить свой собственный сервер? А то твои теоретические балансировки и разграничения доступа не выходят за возможности даже голого MySQL.

файловое хранилище, гибкая балансировка клиентской нагрузки, абстрагирование доступа к базе данных. Универсализация клиентов, возможность мобильных клиентов итп итд. Примеров куча на самом деле. Стоит только взяться за какую либо задачу и начать реализовывать и в боевых условиях попадаешь ногами в жир от недостатоков то базы, то еще какой ерунды. Теория сильно отличается от практики.

файловое хранилище,

Не понял, сервер на Qt будет реализовывать файловое хранилище? И что лучше чем использовать BLOB в базе или простой ftp-сервер?

гибкая балансировка клиентской нагрузки,

Секционирование, кластеризация - решается средствами базы. Шейпинг трафика - решается средствами ОС.

абстрагирование доступа к базе данных.

Решается на уровне клиента, в Qt - драйверами баз.

Универсализация клиентов, возможность мобильных клиентов итп итд

Опять-же, решается использованием какого-нибудь единого фреймворка на стороне клиента.

Теория сильно отличается от практики

Да да. Это в теории хорошо навелосипедить свой универсальный супер-пупер сервер, а на практике проще и быстрее взять готовое решение.

=) я не буду вступать с тобой в полемику, относительно твоих ответов. оставайся при своем мнении. и юзай уже готовые решения на базе 1С или еще какого нибудь говнища. Не всегда готовое решение доступно и перекрывает все хотелки и вписывается в бюджет.

И что лучше чем использовать BLOB в базе или простой ftp-сервер

но мимо этого пройти не смог =)

ftp-сервер = проблема конкурентного доступа к файлам будет основной при использовании такого решения.

BLOB в базе это ад, за такое надо на кол сажать. я видел умельцев засовывающих простые doc html итп файлики в оракл базу, и к чему это приводит при резком повышении объемов работы. Видел базы в 300 гигов объемом? А я видел.

но мимо этого пройти не смог =)

ftp-сервер = проблема конкурентного доступа к файлам будет основной при использовании такого решения.

Ох, лол. Ну, ок, специально для тебя: ftp как самое простое решение, только для чтения. Для конкурентного доступа есть другие варианты в т.ч. сетевых файловых систем с транзакционным доступом. Не надо тут дурачком прикидываться.

BLOB в базе это ад, за такое надо на кол сажать

Посади сначала разработчиков баз, которые придумали BLOB. Наверное они тупее тебя, раз пихают такой ад в свои продукты. Тот же оракель пишет: BLOB's are handy for storing digitized information (e.g., images, audio, video).

Видел базы в 300 гигов объемом?

Ты серъезно? 300 гигов, в 21 веке? Не впечатляет. Для нормальной СУБД пустяковый объем. Да и по железу - ерунда, даже современный домашний десктоп переварит это не вспотев. Объем вообще мало что решает, важно количество запросов в единицу времени.

Велосипедостроение это признак дурного тона в production секторе. Надо искать и применять стандартные решения в стандартных задачах. А иначе поддерживать замучаеться. Если не получаеться скомпилировать драйвер PostgresSQL. Можно поменять базу на MSSQL или Oracle. Эти зрайвера были в стандарной поставке. Можно расшарить файл с SQLite по сети. Вариант с передачей по сети объекта класса QSqlQueryModel не покатит тк там скорее всего содержиться набор указателей на QModelIndex -ы (ячейки с данными). Указатели скопируються, а данные так и остануться на старом месте. (Словите очень много непонятных жёстких ошибок) Если так хочеться свой сервак «с блекджеком и шлюхами» (и SQLite) то можно попробовать реализовать обмен SOAP. Это будет очень правильно и очень красиво. (Хотя труднее чем сборка драйвера)