此场景的 GUID/UUID？还是复合键？或其他

我目前正在开发一个系统，在某些情况下，该系统需要白天在本地数据库上运行，然后在晚上复制到中央服务器。它cannot所有这些都从一个中央数据库运行，因为本地站点会定期与该数据库失去联系。中央服务器上的数据用于仅查看和报告在总部，因此不需要将任何内容反向复制回站点。

每个“站点”都有一个基于文本的唯一密钥（人工生成）。然而，让数据库设计中的每个表都引用站点键的想法并不吸引人。

这是一个非常精简的模式版本的示例without担心远程复制（这对大多数客户端来说都可以正常工作）：-

（为了简单起见，我将仅显示区域表的历史记录表）：

[Site]
SiteKey [PK] (Gauranteed 100% unique across all sites text based key)

[User]
SiteKey [FK -> Site]
UserID [PK]

[Area]
SiteKey [FK -> Site]
AreaID [PK]
Description
UpdatedDtm
UpdatedUserID [FK -> User]

[AreaHistory]
Site [FK -> Site]
AreaID [FK -> Area]
Description
UpdatedDtm
UpdatedUserID [FK -> User]
AuditedDtm

[Location]
AreaID [FK -> Area]
LocationID [PK]
Description
UpdatedDtm
UpdatedUserID [FK -> User]

[Sensor]
LocationID [PK / FK -> Location]
SensorNo [PK]
UpdatedDtm
UpdatedUserID [FK -> User]

[Reading]
LocationID [PK / FK -> Sensor]
SensorNo [PK / FK -> Sensor]
ReadingDtm [PK]

这很好，直到我将数据库与中央服务器上的数据库“合并”。显然，我会在位置表中遇到冲突，因为我将数据与其他站点生成的 ID 混合在一起。

我解决这个问题的第一个方法是这样做：

gs 短）：

[Location]
SiteKey [FK -> Location, FK -> User] ** ADDED THIS
AreaID [FK -> Area]
LocationID [PK]
Description
UpdatedDtm
UpdatedUserID [FK -> User]

[Sensor]
SiteKey [FK -> Location, FK -> User] ** ADDED THIS
LocationID [PK / FK -> Location]
SensorNo [PK]
UpdatedDtm
UpdatedUserID [FK -> User]

[Reading]
SiteKey [FK -> Sensor] ** ADDED THIS
LocationID [PK / FK -> Sensor]
SensorNo [PK / FK -> Sensor]
ReadingDtm [PK]

基本上，每个表都有一个 SiteKey，使得每一行对于该站点都是唯一的。

另一种方法是（在某些地方使用 UUID）：-

[User]
SiteKey [FK -> Site]
UserUUID [PK]

[Area]
SiteKey [FK -> Site]
AreaUUID [PK]
Description
UpdatedDtm
UpdatedUserUUID [FK -> User]

[AreaHistory]
Site [FK -> Site]
AreaUUID [FK -> Area]
Description
UpdatedDtm
UpdatedUserUUID [FK -> User]
AuditedDtm

[Location]
AreaUUID [FK -> Area]
LocationUUID [PK]
Description
UpdatedDtm
UpdatedUserUUID [FK -> User]

[Sensor]
LocationUUID [PK / FK -> Location]
SensorNo [PK]
UpdatedDtm
UpdatedUserUUID [FK -> User]

[Reading]
LocationUUID [PK / FK -> Sensor]
SensorNo [PK / FK -> Sensor]
ReadingDtm [PK]

请记住，这是被删减的，但它说明了问题。

我可能缺少任何替代方案吗？我考虑过重新映射 ID，但这似乎会带来新的、更糟糕的噩梦。

令人烦恼的部分是，只有极少数情况使用这种方案，其余的则对一个数据库为多个站点提供服务感到满意。然而，想要这种场景的客户是最大的;-)

我想也许我可以只为它们使用 UUID，但这意味着在任何地方创建异常，所以如果我要使用它们，也可以在整个过程中使用它们（必要时）。

如果有什么区别的话，我正在使用 PostgreSQL。

PS, this https://stackoverflow.com/questions/45399/advantages-and-disadvantages-of-guid-uuid-database-keys讨论可能与本案相关。我只是一直想知道是否还有另一种方法，考虑到我有一个很好的有保证的独特 SiteKey。

我或多或少得出的结论是，恕我直言，对于这种情况，使用 UUID 是一种“快速修复”，甚至可能是一种黑客攻击。我决定对我来说，在这种情况下，使用复合键更干净。使用 UUID，我还可以将 SiteKey 预先添加到每个 ID 中。