Стратегия сетевого приложения., Помогите определиться, какой путь надежней. Опции

[dzyk]

Имеется приложение. Ядро - база данных SQLite(информация в таблицах изменяется 20-30 раз в день). Сейчас необходимо реализовать одновременное использование БД на нескольких компьюетрах "сети"(постоянных соединений нет, кто-то подключается, кто-то отключатеся, IP динамические, всего 5-6 машин).

Вот мои варианты.

1. Связать приложения по UDP и отсылать каждые х-минут контрольную сумму файла БД SQLite. Если не совпадает то коннект по TCP и клонирование самого свежего файла БД SQLite.

2. Поставить сервер MySQL|PostgreSQL|other (нереально, нет выделенного сервера)

3. Ваше предложение

[AD]

2. Поставить сервер MySQL|PostgreSQL|other (нереально, нет выделенного сервера)

3. Ваше предложение

Вопрос (сорри, если тупой): нельзя одну машину сделать серверной?

[dzyk]

Вопрос (сорри, если тупой): нельзя одну машину сделать серверной?

к сожалению нет, т.к.

1. Нет администраторов
2. Компьютеров в сети максимум 6-7. Ни один из них постоянно работать не будет.

[Novak]

Может, стоит реализовать синхронизацию копий БД, которые хранятся на каждом компе, путём оповещения при каждом изменении?

Ещё вариант - попробовать реализовать своеобразный динамический сервер, то есть данную роль передавать при отключении. Для этого выстроить определённый порядок обращений (с начала по этому ip, потом по другому и т.д.).
В любом случае при этом крайне желательны статические IP

Но лучше всего было бы поставить на один компьютер нормальную СУБД, решается много проблем разом.

[dzyk]

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

Это самый интересный вариант, но сложно.

Развивая Вашу идею:

1 Программы, живущие в настоящее время в сети, вещают в сеть свой IP+контр сумму файла БД+время жизни в онлайн
2 Если контр сумма не совпадает, то кешировавшиеся ранее SQL запросы передаются по TCP тем, кто был в оффлайне ?от программы, которая дольше всех живет в сети.

Самое сложное - создать кэш запросов к БД SQLite, так как в программе используется в основном QSQLTableModel.

[Litkevich Yuriy]

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

Мой вариант такой - ставим на все тачки Git, у каждого своя копия файла БД и при необходимости работать с БД сначало обновляем свою копию БД, средствами Git, он в отличие от Subversion может работать с децентрализованой средой. Но пускать его видимо нодо будет руками, либо выдрать часть кода из QGit - Qt'явая оболчка для Git'а.

[Novak]

Всё же стоит выделить один комп для постоянной работы СУБД, пусть он даже и не будет чистым сервером))
Просто как представишь себе все проблемы работы в подобной децентрализованной среде..

[ViGOur]

dzyk, мне кажется, что ты предложил самое оптимальное решение.
Только вот я не думаю, что целесобразно копировать весь файл бд, лучше просто передавать новые, изменившиеся или удаленные записи.
Так как не понятно до каких размеров вырастет бд, и какая связь у клиентов с тобой. Например те же 10-20Gb постоянно передавать по сети 20-30 раз в день это не мало...

[dzyk]

SQLite не поддерживает транзакции, т.е. к БД одновременно сможет подключатся только одно приложение/компьютер/пользователь

не согласен.
SQLite is a software library that implements a ... transactional SQL database engine.

я не думаю, что целесобразно копировать весь файл бд

Справедливое замечание.

Но я не знаю как кэшировать SQL запросы, я ведь использую класс QSQLTableModel

[ViGOur]

Но я не знаю как кэшировать SQL запросы, я ведь использую класс QSQLTableModel

Нужно подумать как обойти класс QSQLTableModel...

Например у той же Berkeley DB аля логирование, файлы логов, которые создаются при добавлении новой записи, изменении или удалении. Но это как вариант стороны в которую капать...