Клиентская БД - CoreData (iOS)
Серверная БД - MySQL
Я пытаюсь добиться синхронизации данных между клиентом и сервером, но сложность заключается в том, что схема очень реляционная. Я просматривал несколько уже используемых шаблонов синхронизации, и похоже, что большинство из них основано на NOSQL или БД без схемы. Интересно, есть ли какие-нибудь шаблоны синхронизации для высокореляционных данных. Я уже прошел через couchbase, dropbox sync api, wasabi synch и т. Д. Ниже приведены проблемы.
1) Под очень реляционными данными это означает, что существует несколько таблиц, которые связаны друг с другом, и создание / обновление происходит во всех таблицах. Прямо сейчас я планирую выполнять отдельные запросы CRUD для каждой таблицы. Это хороший подход? Но проблема в том, что должен быть строгий порядок запросов, потому что изменения в таблице 3 не могут быть обработаны до получения данных таблицы 2. Эти отношения затрудняют синхронизацию.
2) Отслеживание изменений на клиенте. как лучше всего определить изменения в конкретной таблице (CoreData Entity). Я планирую использовать дельта-подход, при котором за один раз будут загружаться только изменения в объектах аналогичного типа. Любая информация / ссылки на него?
3) Data Merging / ConflictResolution - я наткнулся на эту часть. Один из способов - иметь измененную метку времени в каждом объекте, но что, если даты устройств не синхронизированы или изменены вручную.
Я хотел знать последствия / проблемы в такой схеме синхронизации с сервером, поддерживаемым РСУБД, или любых альтернативных подходах.
Проблема №1 объяснена
Предположим, что существует 10 таблиц, и API-интерфейсы предоставляют запросы CRUD для этих 10 таблиц. 1 Запрос будет выполнять только C / R / U / D любой одной таблицы. Итак, мой вопрос был в том, является ли это хорошим подходом к разработке подобных API, когда дело доходит до автономной синхронизации данных. Например, Рассмотрим реляционные данные
Организация-> Сотрудник-> Отдел-> Проект
Предположим, что некоторые объекты из этих 4 таблиц были созданы в автономном режиме. Теперь нам нужно синхронизировать данные с сервером, когда сеть вернется. Таким образом, это будет похоже на «Сначала создайте / обновите организации», а затем «Создайте / обновите сотрудника», чтобы его можно было связать с организацией. Таким образом, в основном каждый раз, когда C / U / D будет выдаваться от объектов верхнего-> нижнего уровня. Итак, мой вопрос в том, является ли это хорошим подходом к проблеме синхронизации. Потому что, если бы данные не были реляционными, мы могли бы загрузить изменения во все таблицы за один вызов C / U / D API.
