1

这个问题更多的是关于架构和想法，而不是关于代码。

问题：让我们有一个存储所有内容的后端主数据库。然后我们有一个前端本地数据库（SQLLite 或类似的），它只存储用户/设备的相关数据。

用户可以在前端创建数据。然而，多个用户可以同时创建相同的类型（即收据），如果我们使用简单的 int autoincrement PK，后端会发生冲突。

建议的解决方案是：我们使用复合 PK，其中 PK 包括： -autoincrement integer -device ID -user ID

现在，从逻辑上讲，deviceID 和 userID 应该是设备和用户表的 FK，但是由于多种原因，将所有设备/用户存储在每个前端设备上是不切实际的/不可能的，因此 FK 会造成问题。

建议的解决方案是在前端省略 FK req 并仅在后端检查数据完整性，但老实说，我不确定风险/收益是否值得。

有没有人到过这一点和/或在部署它后有一些经验？你觉得呢？你有没有什么想法？非常感谢。

4

1 回答 1

0

弗拉德，

我认为您要解决的难题是：设备如何生成在所有设备上唯一的标识符？过去该问题的答案是创建一个“全局唯一标识符”(GUID) 或“通用唯一标识符”(UUID)，其中包含“设备 ID”、“时间戳”和随机数等唯一标识信息. 可以在此处找到执行此操作的 IETF 标准：RFC4122。

因此，大多数数据库供应商至少提供了一个 UUID() 或 GUID() SQL 函数来返回这些唯一标识符之一。顺便说一句，我不知道SQLLite是否提供了一个，但我知道SequelSphereDB确实提供了 UUID() 函数。最终结果是您可以使用这些来为行创建唯一标识符。

因此，与其拥有由数字、设备 ID 和用户 ID 组成的组合主键，不如使用单列 CHAR(36) 来存储在创建行时动态生成的 UUID。

UUID 优点：

  • 单列
  • 在客户端生成，无需联系任何其他设备
  • “保证”是独一无二的，或者至少比其他可能性要独特得多。

UUID 缺点：

  • 列存储很大：CHAR(38)。
  • 与代理键 one-up 生成器相比，生成速度较慢。
于 2012-11-29T22:11:33.183 回答