Ответ 1
Проблема, которую вы вызываете, не может быть решена в нескольких параграфах или просто ответила. Тем не менее, вот моя попытка...
Во-первых, существует ряд трудностей с принятым вами подходом:
- Клиенты всегда должны подключаться к сети для создания данных и получения ключей от сервера.
- Если вы делаете разные магазины (localstorage и REST), весь код приложения, требующий данных, должен выглядеть в обоих магазинах. Это значительно увеличивает сложность каждой части приложения.
- После создания строки, если вы хотите создать дочерние строки, вы должны дождаться, пока сервер вернет первичный ключ, прежде чем вы сможете ссылаться на него как на внешний ключ в дочерней строке. Для любых умеренно сложных структур данных это становится тяжелым бременем.
- Когда сервер опускается, все клиенты не могут создавать данные.
Вот мой подход. Он использует SequelSphereDB, но большинство концепций можно использовать повторно в других системах управления данными клиентов.
FIRST: используйте UUID для первичных ключей.
Большинство систем управления данными клиентов должны обеспечивать способ генерации универсально уникальных идентификаторов. SequelSphere делает это просто с помощью функции SQL: UUID(). Наличие UUID в качестве первичного ключа для каждой строки позволяет первичным ключам генерировать на любом клиенте в любое время без необходимости связываться с сервером и при этом гарантировать, что идентификаторы будут уникальными. Это также, следовательно, позволяет приложению работать в автономном режиме, не требуя подключения к серверу во время выполнения. Это также заставляет сбитый сервер отключать всех клиентов.
SECOND: используйте один набор таблиц, которые отражают сервер.
Это скорее требование простоты, чем что-либо еще. Это также является требованием для следующих двух основополагающих принципов.
THIRD: для нисходящей синхронизации небольших наборов данных предпочтительнее обновлять данные клиента с сервера.
По возможности выполните полное обновление данных на клиенте с сервера. Это более простая парадигма и приводит к меньшему количеству проблем с целостностью данных. Основным недостатком является размер данных при передаче.
ЧЕТВЕРТЫЙ: для нисходящей синхронизации больших наборов данных выполните обновления Transactional
Здесь мой подход становится немного более сложным. Если набор данных слишком велик и требуется только синхронизировать измененные строки, вы должны найти способ их синхронизации в соответствии с "транзакциями". То есть: вставляет/обновляет/удаляет в том порядке, в котором они были выполнены на сервере, чтобы обеспечить простой script для выполнения на клиенте.
Предпочтительно иметь на сервере таблицу, на которой записываются транзакции, которые должны быть синхронизированы с устройством. Если это невозможно, заказ часто может быть записан на сервере с использованием меток времени в строках, а клиент запрашивает все изменения с определенной отметки времени. Big Negative: вам нужно будет отслеживать удаленные строки либо путем "логического" удаления, либо путем отслеживания их в своей таблице. Даже при этом изолирование сложности сервера предпочтительнее распространять его на всех клиентов.
FIFTH: для восходящей синхронизации используйте обновления Transactional
Здесь SequelSphereDB действительно светит: он будет отслеживать вас о всех вставках, обновлениях и удалениях, выполняемых против таблиц, а затем предоставлять их обратно во время синхронизации. Он даже делает это через перезапуск браузера, поскольку он сохраняет информацию в localstorage/indexeddb. Он даже обрабатывает фиксации и откаты соответственно. Клиентское приложение может взаимодействовать с данными, как обычно, без необходимости задумываться над записью изменений, а затем использовать SequelSphereDB "Change Trackers" для воспроизведения изменений во время синхронизации.
Если вы не используете SequelSphere (вы должны быть), сохраните на клиенте отдельную таблицу для записи всех вставок, обновлений и удалений, выполняемых клиентом. Всякий раз, когда клиентское приложение вставляет/обновляет/удаляет строки, сделайте копию этого в таблице "транзакция". При восходящем времени синхронизации отправьте их. На сервере просто выполните те же шаги в том же порядке, чтобы реплицировать данные, которые были на клиенте.
ТАКЖЕ ВАЖНО: всегда выполняйте синхронизацию вверх до полного обновления клиентских таблиц с сервера.:)
Заключение
Я предлагаю перейти на простоту по сложности в максимально возможное количество мест. Использование UUID для первичных ключей чрезвычайно полезно для этого. Использование каких-то "трекеров изменений" также очень полезно. Использование такого инструмента, как SequelSphereDB для отслеживания изменений для вас, является наиболее полезным, но не необходимым для этого подхода.
ПОЛНОЕ РАСКРЫТИЕ: Я тесно связан с компанией SequelSphere, но этот продукт действительно не нужен для реализации вышеуказанного подхода.