У нас есть локальный сервер с базой данных доступа, которая передает данные клиентам в том же домене. Теперь у нас также есть веб-сайт, который размещен на внешних серверах и работает над созданием мостовой системы для обеспечения загрузки / загрузки функций продуктов, категорий и заказов и т. Д.
Продукты, категории, клиенты и т. Д. Можно добавлять только локально, однако заказы можно добавлять как локально, так и на веб-сайте. Мы пытаемся синхронизировать их с помощью приложения-моста, которое использует веб-службы. У нас это работало, но мы столкнулись с большим количеством проблем. Наш текущий подход:
- Каждая отдельная запись имеет локальный идентификатор (luid) и идентификатор веб-сервера (suid), одним из примеров использования которого является то, что когда элемент добавляется на веб-сайт, ему присваивается уникальный suid, а значение luid равно -1, элемент загружается приложением-мостом, применяется и обновляется luid. Это обратное для элементов, добавляемых на локальный сервер.
- Каждая индивидуальная запись также имеет поле флага (выделение вставки, обновления, удаления (с веб-сайта) и удаления).
Вышесказанное работает хорошо - кроме подхода luid и suid стало невозможным легко отслеживать отношения записи после загрузки элемента. Кажется, что этот подход хорошо работает только для односторонних данных - то есть просто загружать продукты на веб-сайт для просмотра (и динамически обновлять и удалять их).
Чтобы решить эту проблему, я рассмотрел использование GUID или, возможно, подхода GUID COMB, что означает, что элементы могут быть добавлены с обеих сторон и синхронизированы соответствующим образом, хотя производительность меня немного беспокоит.
Некоторые важные моменты:
- Локальный сервер - это «базовый лагерь» данных, где все должно (в конечном итоге) храниться.
- Только приложение локального моста может отправлять запросы на веб-сервер из-за веб-служб.
- Необходимо поддерживать вероятность того, что не всегда может быть подключение к Интернету, поэтому запрос уникальных идентификаторов с веб-сервера не идеален.
Есть ли у кого-нибудь мнение о гораздо лучшем подходе к программированию для обработки такого рода «синхронизации»?