Ради скорости и независимости от сетевого соединения мобильное приложение должно использовать локальную базу, которая периодически синхронизируется с рабочей базой данных предприятия. Пусть мобильная БД состоит из таблиц
М1, М2,... Мn и используется только для чтения. Таблицы имеют целочисленные первичные ключи. Рассмотрим вариант однонаправленной синхронизации:
Версию данных будем обозначать целым числом и хранить в отведенной для этого таблице. 0 -- соответствует чистой БД.
На сервере создадим таблицы S1, S2,... Sn, идентичные по структуре таблицам из мобильной БД. Указанные таблицы хранят текущую версию данных на сервере.
На сервере создадим GLOBAL TEMPORARY таблицы уровня транзакции T1, T2,... Tn, также как и S идентичные по структуре таблицам из мобильной БД.
На сервере создадим таблицу для команд обновления данных. Каждая запись таблицы хранит в текстовом виде список команд для перевода версии J в версию K.
Команда состоит из заголовка и тела (или только из заголовка). Поддерживаются следующие команды:
RALL -- очистить все таблицы.
R -- очистить одну таблицу. В заголовке передается имя таблицы.
D -- удалить записи из таблицы. В заголовке передается имя таблицы. В теле -- список ИД удаляемых записей.
U -- вставить или обновить записи в таблице. В заголовке передается имя таблицы и список полей. В теле передаются значения полей для каждой записи. Первое значение -- всегда ИД записи. Так как присутствие идентификатора обязательно, в списке имя поля первичного ключа не перечисляется.
Для одной и той же таблицы в списке может присутствовать неограниченное число команд.
Значения полей конвертируются в текстовое представление. Для их разделения, а также для разделения команд используются управляющие символы.
Процедура формирования очередной версии данных на сервере вызывается вручную или автоматически, по установленному расписанию:
Стартует транзакция.
Сформированные данные данные помещаются в таблицы T.
На основе сравнения S и T создаются и записываются в журнал команды изменения данных от версии N к N + 1.
Таблицы S очищаются, в них переносятся записи из T.
Инкрементируется номер версии данных.
Транзакция завершается.
Диалог между мобильным приложением и сервером:
Мобильное приложение подключается к серверу и сообщает свою версию структуры БД и версию данных (V).
Если версия структуры БД нас не устраивает, то сообщаем пользователю, что приложение следует обновить.
Из журнала извлекаем команды для обновления данных от версии V к N и передаем их мобильному приложению.
Если у нас нет прямого перехода от V к N, то последовательно ищем команды для апгрейда от V до V + 1 и формируем из них единый список для инкрементного обновления.
Передаем список команд на мобильное устройство.
По окончании процесса применения полученных команд инкрементируем номер версии данных мобильного приложения.
Если мобильное приложение передало на сервер 0, то вместо передачи длинной цепочки последовательных обновлений, сразу формируем команды на основе содержимого таблиц S.
Процесс обновления выполняется на одной транзакции, которая подтверждается только в случае успешного выполнения всех команд.
Комментариев нет:
Отправить комментарий