У меня есть интернет-приложение, которое поддерживает автономный режим, когда пользователи могут создавать данные, которые будут синхронизироваться с сервером, когда пользователь снова будет подключен к сети. Поэтому из-за этого я использую UUID для идентификации в моей базе данных, поэтому отключенные клиенты могут создавать новые объекты, не опасаясь использовать идентификатор, используемый другим клиентом, и т.д. Однако, хотя это отлично работает для объектов, принадлежащих этому пользователю, являются объектами, которые совместно используются несколькими пользователями. Например, теги, используемые пользователем, могут быть глобальными, и нет возможности, чтобы удаленная база данных могла хранить все возможные теги во вселенной.
Если автономный пользователь создает объект и добавляет к нему некоторые теги. Скажем, эти теги не существуют в локальной базе данных пользователя, поэтому программное обеспечение создает для них UUID. Теперь, когда эти теги синхронизированы, для разрешения любого совпадения потребуется процесс разрешения. Некоторые способы сопоставления любых существующих тегов в удаленной базе данных с локальными версиями.
Один из способов - использовать какой-то процесс, с помощью которого глобальные объекты разрешаются естественным ключом (имя в случае тега), а локальная база данных должна заменить существующий объект тем, что он является глобальным. Это может быть беспорядочно, когда есть много соединений с другими объектами. Что-то подсказывает мне избегать этого.
Другой способ справиться с этим - использовать два идентификатора. Один глобальный идентификатор и один локальный идентификатор. Я надеялся, что использование UUID поможет избежать этого, но я продолжаю идти туда и обратно между использованием одного UUID и использованием двух разделенных идентификаторов. Использование этой опции заставляет меня задаться вопросом, не позволил ли я проблеме выйти из-под контроля.
Другой подход - отслеживать все изменения через не общие объекты. В этом примере объект, которому пользователь назначил теги. Когда пользователь синхронизирует свои автономные изменения, сервер может заменить свой локальный тег на глобальный. В следующий раз, когда этот клиент синхронизируется с сервером, он обнаруживает изменение не общего объекта. Когда клиент сбрасывает этот объект, он получит глобальный тег. Программное обеспечение просто переустановит не общий объект, указывая его на тег сервера и осировая его локальную версию. Некоторые проблемы с этим - дополнительные круглые поездки для полной синхронизации и дополнительные данные в локальной базе данных, которая просто осиротела. Существуют ли другие проблемы или ошибки, которые могут возникнуть, когда система находится между состояниями синхронизации? (т.е. пытаться разговаривать с сервером и отправлять ему локальные UUID для объектов и т.д.).
Другая альтернатива - избегать общих объектов. В моем программном обеспечении это может быть приемлемым ответом. Я не делаю много обмена объектами между пользователями, но это не значит, что я не буду делать это в будущем. Это означает, что выбор этой опции может парализовать мое программное обеспечение в будущем, если мне нужно добавить эти типы функций. Для этого есть последствия, и я не уверен, полностью ли я их изучил.
Итак, я ищу любую лучшую практику, существующие алгоритмы для обработки этого типа системы, руководство по выбору и т.д.