sql - 这种情况下的 GUID/UUID？还是复合键？或其他

Question

我目前正在开发一个系统，该系统在某些情况下需要白天在本地数据库上运行，然后在夜间复制到中央服务器。它不能全部从一个中央数据库运行，因为本地站点会定期与它失去联系。中央服务器上的数据仅供总部查看和报告使用，因此无需反向复制回站点。

每个“网站”都有一个基于文本的唯一键(人工生成)。但是，让数据库设计中的每个表都引用站点 key 的想法并不吸引人。

这是一个非常简化版本的架构示例，无需担心远程复制(这对大多数客户端来说都可以正常工作):-

(为了简短起见，我只会显示 Area 表的历史表):

[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]

这很好，直到我将数据库与中央服务器的数据库“合并”。我显然会在 Location 表中发生冲突，因为我将数据与在其他站点生成的 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。

附言，this讨论可能与本案有关。我一直想知道是否有另一种方法考虑到我有一个很好的 gauranteed 唯一 SiteKey。

Answer 1

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