Синхронизация баз данных

[Karl-Philipp]

Изменения в БД магазина доложны анализироваться на удалённом компьютере. Для этого на удалённом компьютере создаётся аналогичная база, куда будут передаваться изменения (в виде запросов) каждые 2-10 минут для синхронизации и последующего анализа.

Основная цель темы - обеспечить самую быструю и надёжную передачу данных (запросов) на удалённый компьютер.

Вопросы:
1) как лучше передавать запросы между БД магазина и удалённым компьютером? Ответ: Почитал про сокеты, потом про QNetworkAccessManager, вроде бы подходят, а что лучше (быстрее, надёжнее)?
2) как передавать данные? Нашёл такую вещь как QByteArray, тоже вроде бы подходит.

upd: удалённый компьютер, на котором анализируются данные находится от магазина (ов) на расстоянии от нескольких километров до двух тысяч километров.

[ecspertiza]

Недавно занимался похожей темой, посмотри в сторону SOAP довольно токи удобная весчь. и у КуТе классы для работы с ним есть  http://doc.trolltech.com/solutions/3/qtsoap/qtsoap-overview.html.

[Karl-Philipp]

ecspertiza!
похоже, то, что надо. Спасибо большое

[UVV]

Ice ?

[Karl-Philipp]

Ice использует бинарный протокол передачи данный, и это действительно айс(уж куда пошустрее будет XML в SOAP).
Но не айс то, что технология распространяется под двойной лицензией: GNU GPL или коммерческой. Покупать возможности нет, а вот закрыть код надо.
Хотя программа будет использоваться фактически внутри фирмы. Вот тут то возникают вопросы... по поводу закрытия кода. Можно ли?

[Karl-Philipp]

только вот незадача то:
мне же надо передать всего ничего - одну строчку(запрос). Правда в случае разрыва соединения, когда оно восстановится придется передавать десятки, возможно тысячи строчек. Хотя это не меняет сути темы.

Может все-таки QTcpSocket + QDataStream

[ecspertiza]

Если чесно я пока не знаю что ты выбрал SOAP или Ice или что то ещё, но могу сказать про SOAP то что ты в неё можешь передавать не строчку запроса а данные из таблицы которые необходимо синхронизировать и генерить запрос на лету при приёме данных, Soap имеет замечательную особенность у него данные либо дошли либо нет. А в клиентской части пишешь грамотный парсинг и в общем то всё, там уже будет всё равно сколько строчек пришло.

[UVV]

Вот тут то возникают вопросы... по поводу закрытия кода. Можно ли?

Небольшое непонимание лицензии GPL. Если ты пишешь для своей организации и не собираешься продавать приложение кому-либо другому, то ты ничего не нарушаешь. Правда в случае Ice, у тебя структура системы должна измениться =)
Насчёт гарантии доставки, я пока не понял, как Ice себя ведёт в случае разрыва связи... т.е. как её грамотно восстановить =)
http://www.zeroc.com/faq/connectionClosureCallback.html

[Karl-Philipp]

>>Правда в случае Ice, у тебя структура системы должна измениться =)
а можно по-подробнее, пожалуйста. Как это она должна измениться?

[MrLink]

Я конечно не спец по синхронизациям БД. Но этот вопрос изучал, и кое-что делал. У меня возникли вопросы: как Вы намереваетесь обрабатывать ошибочные ситуации? Например, обрыв связи во время передачи или отключение интернета на длительное время, а также, возможное, дублирование записей (насколько я помню, это называется коллизией) и т.д. и т.п. Вообщем как будет обеспечиваться надёжность?

[crossly]

какая БД используется??

[Karl-Philipp]

Я конечно не спец по синхронизациям БД. Но этот вопрос изучал, и кое-что делал. У меня возникли вопросы: как Вы намереваетесь обрабатывать ошибочные ситуации? Например, обрыв связи во время передачи или отключение интернета на длительное время, а также, возможное, дублирование записей (насколько я помню, это называется коллизией) и т.д. и т.п. Вообщем как будет обеспечиваться надёжность?

Подобные вопросы возникали и у меня. Только вот проект заморозился.
Планировалось использовать Mysql.

[crossly]

может стоит задуматся о нормальной СУБД с поддержкой репликаций...

[ритт]

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

посмотри google protobuf. оно, конечно, далеко от совершенства, но по возможностям сильно обходит soap

[Karl-Philipp]

да,да, мы уже говорили об protobuf, тогда они еще назывались, вроде бы google protocols