database-design - 在关系数据库中实现全局唯一标识符的优缺点和方法？

Question

关于我问题的第一部分:我最近问自己在关系数据库中为某些表使用唯一标识符有什么好处和权衡。举个例子，Facebook (FB) Graph API 允许使用相同的 URL 获取不同类型的对象，例如“用户”、“事件”、“页面”等，例如 https://domain/251906384206返回一个“事件”类型的对象，而 https://domain/195466193802264返回一个“组”类型的对象。

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

关于问题的第二部分:实现全局唯一标识符有哪些选项？

我想到的两个选项是:

使用基于继承的方法(每类表、单表等)。假设使用 table-per-class 方法( super 表仅包含唯一标识符作为主键，表示对象类型的子表包含与 super 表相同的标识符和附加数据)， super 和子表之间需要连接，这似乎很糟糕因为 super 表成为瓶颈？

提供一个包含 3 列的表格，其中包含

唯一标识符，

对象类型特定的主键，以及

表名。

每个对象类型的附加表包含将唯一标识符作为外键引用的列。每个对象类型特定的表都有它自己的主键范围。
这两种方法都允许提供像上面提到的 FB API 一样的通用 API。第二种方法将允许在内部使用对象表特定的主键并仅公开全局唯一标识符。但是，如果可以在内部使用全局唯一标识符，则第二种方法也需要连接。

是否有任何关于全局唯一标识符的优缺点的经验以及实现它的最佳实践是什么？

Answer 1

“一个问题说得好，就是一个已经解决了一半的问题”。

在我看来，您正在混合几个概念。您检查了其他数据库应用程序，但似乎您更困惑而不是更了解情况。

您有几个不同类的对象，您想知道如何将它们存储在数据库中。这通常被称为对象关系映射 (O.R.M.) 的“花哨名称”。

此外，您希望使用全局唯一标识符 (G.U.I.D.) 将对象标识为业务/编程对象和表中的行。

此外，您还想使用 G.U.I.D.识别特定类型的类或对象。

假设您正在构建一个应用程序。你有几个对象。对象有多种类别，例如“用户”、“事件”、“页面”等。您可以拥有多个相同类/类型的对象，但您需要一种方法来识别另一个对象。识别来自密歇根州的“John Doe”，来自昆士兰州的“John Doe”。假设您的对象将使用 G.U.I.D 类型的属性。

因此，让我们假设您为每个类创建一个表(“用户”表示“用户”，表标准 ID 是单数和小写，但您可以忽略它，“事件”表示“事件”，等等)。每个表都有几个字段，代表每个对象的属性。所以“用户”会有一个像“user_key GUID”这样的字段，可能还有“user_name varchar(100)”和“user_birthdate datetime”。其他表也是如此。

我使用了“supertable”，但仅用于非常具体的而不是常见的应用程序。我认为您不需要一个混合“用户”、“事件”、“页面”的表格。我有一个案例，我们有一个 super 表“customers”，加上带有特定附加字段的“company”和“person”子表。有时，我们必须检查所有客户的销售额，并与“客户”表建立连接。有时，我们不得不为产品提供公司折扣，并浏览“公司”子表。

如果你想要这个泛化/“是一个” super 表，你不需要 super 表主键和详细表主键有不同的字段，可以是相同的类型。

我建议不惜一切代价避免使用复合/复合键(“主键”加“其他”字段)，使用单个字段主键。我还建议分配 G.U.I.D. key 使用编程，不在数据库中。

G.U.I.D.比整数键使用更多的内存和磁盘空间，但是，它非常快速且容易获得很难复制的键。

同样，您的问题更多的是如何表示数据库中的对象，而不是 G.U.I.D 的使用。