我有一个支持离线模式的互联网应用程序，用户可以创建数据，当用户重新在线时，这些数据将与服务器同步。因此，正因为如此，我在我的数据库中使用 UUID 作为标识，因此断开连接的客户端可以生成新对象，而不必担心使用另一个客户端使用的 ID 等。但是，虽然这对于该用户拥有的对象非常有用是由多个用户共享的对象。例如，用户使用的标签可能是全局的，远程数据库不可能保存宇宙中所有可能的标签。
如果离线用户创建一个对象并为其添加一些标签。假设这些标签在用户的本地数据库中不存在，因此软件会为它们生成一个 UUID。现在，当这些标签同步时，需要一个解析过程来解决任何重叠。将远程数据库中的任何现有标签与本地版本匹配的某种方式。
一种方法是使用某个过程，通过该过程，全局对象由自然键（在标签的情况下为名称）解析，并且本地数据库必须用全局数据库中的这个对象替换它的现有对象。当与其他对象有很多连接时，这可能会很混乱。有些东西告诉我要避免这种情况。
另一种处理方法是使用两个 ID。一个全局 ID 和一个本地 ID。我希望使用 UUID 有助于避免这种情况，但我一直在使用单个 UUID 和使用两个拆分 ID 之间来回切换。使用这个选项让我想知道我是否让问题失控了。
另一种方法是通过非共享对象跟踪所有更改。在此示例中，用户分配了标签的对象。当用户同步他们的离线更改时，服务器可能会用全局标签替换他的本地标签。下次此客户端与服务器同步时，它会检测到非共享对象的更改。当客户端拉下该对象时，他将收到全局标签。该软件将简单地重新保存指向服务器标签的非共享对象并孤立他的本地版本。与此相关的一些问题是完全同步的额外往返行程，以及刚刚孤立的本地数据库中的额外数据。当系统处于同步状态之间时，是否还会发生其他问题或错误？（即尝试与服务器通信并向其发送对象的本地 UUID 等）。
另一种选择是避免常见的对象。在我的软件中，这可能是一个可以接受的答案。我不会在用户之间进行大量对象共享，但这并不意味着我将来不会这样做。这意味着如果我需要添加这些类型的功能，选择此选项可能会在将来使我的软件瘫痪。这种选择是有后果的，我不确定我是否已经完全探索过了。
因此，我正在寻找任何类型的最佳实践、处理此类系统的现有算法、选择指南等。