数据库设计 – 在关系数据库中实现全局唯一标识符的优点/缺点和方法?

前端之家收集整理的这篇文章主要介绍了数据库设计 – 在关系数据库中实现全局唯一标识符的优点/缺点和方法?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
关于我的问题的第一部分:我最近问自己,为关系数据库中的某些表提供唯一标识符有什么好处和权衡.举个例子,Facebook(FB)图谱API允许使用相同的URL获取不同类型的对象,如“用户”,“事件”,“页面”等,例如 https://domain/251906384206返回“事件”类型的对象而 https://domain/195466193802264返回“Group”类型的对象.

与提供较少“通用”API相比,这种方法有什么好处,可以这样使用:https://domain/event/251906384206https://domain/group/195466193802264.在这种情况下,类似的标识符可能用于不同的对象类型,因为每个对象类型都有它标识范围.

关于问题的第二部分:实施全球唯一标识的选项有哪些?

我想到的两个选择是:

>使用基于继承的方法(每个表,单个表等).假设使用了每类表方法(超级表仅包含唯一标识符作为主键,表示对象类型的子表包含与超级表和附加数据相同的标识符),超级表和子表之间需要连接,这似乎很难扩展因为超级表成为瓶颈?
>提供包含3列的表格

>唯一标识符,
>对象类型特定的主键,和
>表名.

每个对象类型的附加表,包含引用唯一标识符作为外键的列.每个特定于对象类型的表都有自己的主键范围.

这两种方法都允许提供类似上面提到的FB API的通用API.第二种方法允许在内部使用对象表特定的主键,并仅显示全局唯一标识符.但是,如果可能在内部使用全局唯一标识符,则第二种方法也需要连接.

是否有关于全球唯一标识符的优缺点的经验以及实施它的最佳实践?

解决方法

您提出的两种实现全局标识符的方法都涉及大表的连接以及数据库中记录数量的有效加倍(每个对象本身都存在,但父级/记录的全局ID也是如此).

我觉得在应用程序/数据访问层中强制执行全局ID会更好.
这可以通过强制执行每个特定类型的对象的ID仅来自可能ID的子集来完成.例如,您可以保留所有ID的最后/前x位以指定对象类型. ID的剩余部分将是“实际ID”.

如果您在为spefic表分配ID时担心错误,则可以添加一个检查约束,以强制ID正确(例如ID <4000和ID> 10000).如果您担心在其标识符中浪费了对象类型的位/字节,则只能在数据库访问API中公开全局ID,这会将对象的ID(实际存储在表中)与其类型ID连接起来(派生自对象类型).

猜你在找的MsSQL相关文章