Sch*_*lle 7 database-design primary-key uniqueidentifier relational-database unique-key
关于我的问题的第一部分:我最近问自己,为关系数据库中的某些表提供唯一标识符有什么好处和权衡.举个例子,Facebook(FB)图谱API允许使用相同的URL获取不同类型的对象,如"用户","事件","页面"等,例如https:// domain/251906384206返回"事件"类型的对象,而https:// domain/195466193802264返回"Group"类型的对象.
与提供较少"通用"API相比,此方法的好处是什么,将以这种方式使用:https:// domain/event/251906384206或https:// domain/group/195466193802264.在这种情况下,类似的标识符可能用于不同的对象类型,因为每个对象类型都有它的标识符范围.
关于问题的第二部分:实施全球唯一标识的选项有哪些？
我想到的两个选择是:
使用基于继承的方法(每个表,单个表等).假设使用了每类表方法(超级表仅包含唯一标识符作为主键,表示对象类型的子表包含与超级表和附加数据相同的标识符),超级表和子表之间需要连接,这似乎很难扩展因为超级表成为瓶颈？
提供包含3列的表格
每个对象类型的附加表,包含引用唯一标识符作为外键的列.每个特定于对象类型的表都有自己的主键范围.
这两种方法都允许提供类似上面提到的FB API的通用API.第二种方法允许在内部使用对象表特定的主键,并仅显示全局唯一标识符.但是,如果可能在内部使用全局唯一标识符,则第二种方法也需要连接.
是否有关于全球唯一标识符的优缺点的经验以及实施它的最佳实践？
您提出的两种实现全局标识符的方法都涉及大表的联接以及数据库中记录数量的有效加倍（每个对象都单独存在，但其父级/记录及其全局 ID 也存在）。
我有一种感觉，在应用程序/数据访问层中强制执行全局 ID 会更好。这可以通过强制每个特定类型的对象的 ID 仅来自可能 ID 的子集来轻松完成。例如，您可以保留所有 ID 的最后/前 x 位来指定对象类型。ID 的其余部分将是“实际 ID”。
如果您担心在为特定表分配 ID 时出现错误，您可以添加一个检查约束来强制 ID 正确（例如 ID < 4000 AND ID > 10000）。如果您担心标识符中对象类型浪费的位/字节，则可以仅在数据库访问 API 中公开全局 ID，这会将对象的 ID（实际上存储在表中）与其类型 ID 连接起来（从对象类型派生）。