跨数据库共享单个主键序列？

Question

在所有表中使用单个序列作为主键（而不是主键对于给定表是唯一的，它对于所有表都是唯一的）是否可以接受？如果是这样，客观上是否比跨表使用单个主键序列更好。

我是一名初级软件开发人员，而不是 DBA，所以我仍在学习良好数据库设计的许多基础知识。

编辑：如果有人想知道，我最近阅读了我们公司的一位 DBA 对数据库设计的评论，他提到设计没有在整个数据库中使用单个主键是一个问题，这听起来与到目前为止我已经学会了。

Edit2：要回答评论中的问题，这是针对 Oracle 11g 的，但我想知道非数据库特定级别。如果这个问题确实取决于数据库，我很想知道原因，但在这种情况下，我会寻找特定于 Oracle 的答案。

Answer 1

可以接受吗？当然。常见的？不。有益吗？疑。

在我的旧工作中，我们继承了一个系统，其中有一个中央序列生成器（这是一个 SQL Server 系统，早SEQUENCE在 SQL Server 2012 中引入之前）。这并不是真正的性能瓶颈，除非您每秒生成数十万个值，否则不应该是。但它使所有代码比它必须的复杂得多，没有充分的理由。设计的目的是确保如果系统中的某个东西被分配了 12 的 ID 值，那么系统中只有一个东西的 ID 可以是 12。这对我来说似乎很迟钝，我从来没有理解过。如果我有一个 CustomerID = 12 的客户，为什么这会阻止我订购 OrderID = 12 的订单？

如果您有多个系统并且您正在从这些多个系统为某种类型的实体（例如客户或订单）生成 ID，我确实看到了中央序列生成器的用处。一个中央序列可以向多个系统分发新值，而不会成为瓶颈（只是一个单点故障），也不必担心两个系统会生成相同的 ID。

Answer 2

这个想法在一个非常复杂的数据库中是有价值的，在这种数据库中人们可能会意外地使用错误的列加入到一个表中，并且仅仅因为 INT ID 是相同的而得到无效的行。

我们选择将顺序 GUID 作为我们的主键，以避免 GUID 的一些索引碎片陷阱。可悲的是，它们相当大。

SQL Server 可以通过默认调用 newSequentialID() 函数生成顺序 GUID，因此没有要维护的已发布密钥表，也没有阻塞瓶颈。

这实际上为我们提供了跨整个数据库、跨整个企业的唯一 ID，因为它们确实是独一无二的。

价格当然是空间，当您尝试将数据带到数据仓库/立方体时，它的问题在于速度/大小取决于使用较小的整数键。

我相信我们通过使用它们已经避免了我们应用程序中的许多错误。