Как люди обрабатывают внешние ключи на клиентах при синхронизации с master db

Question

Я пишу приложение с поддержкой в ​​автономном режиме.то есть браузерные / мобильные клиенты синхронизируют команды с главной базой данных очень часто.

Я использую uuid как на стороне клиента, так и на стороне сервера.При синхронизации с сервером сервер будет возвращать карту локальных uuids (luid) в uuids сервера (suid).После получения этой карты клиенты обновили свои атрибуты suid записей соответствующими значениями.

Однако, скажем, запись клиента, например, todo, имеет атрибут list_id, который содержит внешний ключ к записи списка todos.,Я использую luids в foreign_keys на клиентах.Однако, когда этот атрибут отправляется на сервер, он загрязняет базу данных сервера luids, а не suid, который использует сервер.

Мое текущее решение заключается в том, чтобы главный сервер вел учет сопоставлений luids и suids (для каждого идентификатора клиента), и для каждого внешнего ключа в команде найдите suid для этого конкретного клиента и используйтевместо этого suid.

Мне интересно, сталкивались ли другие с такой проблемой, и если да, то как они решили ее?Есть ли более эффективный, более простой способ?

Я посмотрел на этот вопрос "Синхронизация одной или нескольких баз данных с основной базой данных - внешние ключи (5)", и кто-то, кажется, предложил мое текущее решение в качестве одного из вариантовсоставные ключи, использующие suids и автоинкрементные последовательности, и другой параметр, использующий идентификаторы -ve для идентификаторов клиентов, а затем обновляющие все отрицательные идентификаторы с помощью suids.Оба эти других варианта кажутся гораздо более сложными.

Спасибо,

Саймон

Answer 1

Я только что подумал о другой возможности:

При назначении жидкостей на стороне клиента сохраняйте карту всех назначений, например,

что-то вроде (json):

  {
   'luid123': [{model: list, attribute: 'id'}, 
             {model: todo, attribute: 'list_id'}]
  }

Когда мы получаем глобальную карту luid2suid с сервера (после синхронизации), для каждого luid мы ищем luid на карте luid и для каждой записи обновляем соответствующий атрибут в соответствующей модели с помощью guid и удаляем запись из картографирования.

Что ты думаешь?

Таким образом, я избегаю дорогостоящих поисков в глобальной карте luid2suid для всех синхронизируемых внешних ключей команд. Еще одно преимущество заключается в том, что все внешние ключи также являются suid-файлами на клиенте, и мне нужно будет только искать suid-ы из luids на стороне сервера для случаев создания и изменения автономных записей перед синхронизацией с сервером.

Это просто идея, которая пришла мне в голову. Я все еще надеюсь получить больше отзывов на эту тему

Answer 2

Исходя из моего опыта, проще всего использовать композиционный подход, особенно когда речь идет об отладке проблем и потенциальных потребностях для отката, то есть действительно полезно знать, какие запросы пришли с какой машины и привели к каким изменениям. Всякий раз, когда вы эффективно имеете дело со многими к одному, у вас должен быть способ эффективно изолировать все это, это также позволяет вам более интеллектуально управлять конфликтами, когда у вас есть два из множества отправляющих обновлений, которые не дополняют друг друга. (если вы хотите делать такие вещи).