Каковы основные проблемы создания приложения для iPhone, которое синхронизирует данные с сервером через веб-API?

Question

Я хочу создать приложение, которое использует данные с сервера, и оно должно синхронизировать данные в приложении с данными, введенными другими клиентскими приложениями. Итак, есть несколько вопросов:

• Как эффективно разработать схему базы данных? Должен ли он реплицировать ту же схему базы данных на сервере или добавить еще несколько полей и сущностей?
• Каковы стратегии синхронизации данных при каждом запуске приложения или во время неактивного состояния приложения, или что-то еще ...
• Как обрабатывать конфликт данных, введенных пользователем в приложение, и данных, введенных другим клиентским приложением.

Любой ответ приветствуется.

Answer 1

Итак, вы определили основные проблемы в своем первоначальном вопросе. Реальный ответ заключается в том, что это не имеет ничего общего с iPhone - репликация базы данных просто очень трудно .

Вот несколько практических правил, которые я могу предложить:

• односторонняя репликация данных в миллион раз проще, чем двусторонняя репликация, если вам это сойдет с рук.

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

• Чтобы выполнить двустороннюю репликацию, вам нужно либо хранить отметок времени для каждой строки на каждом конце, , либо сохранять полное содержимое одного конца на другом конце. (т.е. сервер должен знать самый последний статус клиента, или клиент должен знать самый последний статус сервера).

• , чтобы разрешить добавление строк от отключенных клиентов, вам нужно идентифицировать ваши строки, используя GUID (или хэш, например, SHA-1), а не поле автоинкремента. Можно добавить новые строки, добавленные клиентом, как «без идентификатора», пока вы не синхронизируете их с сервером, но в этом случае безумие.

• * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Несовершенные варианты включают в себя последние выигрыши автора (последний, кто синхронизирует измененную запись, получает свою копию записи) -way-merge (когда кто-то отправляет измененную запись, проверяет, какие столбцы были изменены, и изменяет только эти столбцы, таким образом не перезаписывая изменения в других столбцах), разделяется на две записи (если два человека вносят изменения в ту же запись, просто сделайте две записи и предположите, что кто-то исправит это в конце концов), и «спросите пользователя» (что технически наиболее обоснованно, но требует много работы с пользовательским интерфейсом, и пользователи редко понимают, что такое конфликт, даже ).