同时使用 GUID 和自动递增整数

Question

我一直在研究使用 GUID 作为数据库中的主键。目前看来，利大于弊。但是，我发现 GUID 可能不是我想要的。

在我的应用程序中，用户应该能够根据用户友好的 ID 识别对象。因此，例如，如果他们想在不输入全名的情况下获得特定产品，他们可以使用产品的 ID。对于这样的事情，GUID 不容易记住。

我一直在考虑的解决方案是同时使用 GUID 和自动递增整数。 GUID 将是行的主键，而自动递增整数将是应用程序过滤函数使用的索引。但是，所有 SQL SELECT、UPDATE、DELETE 语句都将使用 GUID。

我想使用 GUID 的主要原因是为了防止在合并两个数据库时发生冲突。如果 Database #1 和 Database #2 都具有 Product #2，则导入器脚本必须更改 ID 和引用它的所有外键。使用 GUID，我只需更改表本身的用户友好 ID，而外键将使用每个导入记录唯一的 GUID，因此无需修改即可工作。

所以，我的问题是：具有自动递增整数索引和 GUID 主键是否存在任何重大问题（除了 GUID 字段的大小和容易的页面碎片）？

Answer 1

我总是倾向于在我的数据库中使用代理主键。 也就是说：那些主键在问题域中没有实际意义，因此，这些主键永远不会暴露给用户。 （如果这个代理主键的类型是 GUID 或标识，我不在乎；这取决于要求）。

如果您说用户应该能够根据用户友好的 ID 识别对象，那么，我认为这个用户友好的 ID 是属于您的“问题域”的值。 这意味着，这个 ID 确实应该是您表中的一个属性，但它不应该用作您的表中的主键。

这还允许您轻松修改此类用户友好 ID 的值（如果有必要），而不必担心修改相关的外键。

Answer 2

“为什么“用户应该能够根据用户友好的 ID 识别对象”？

在我看来，您的用户应该使用代码来识别记录。

假设您的数据库包含产品（正如您在问题中提到的那样）。如果他们有代表产品的代码，用户可以输入，那不是更好吗？

假设您有桌子和椅子，作为用户，我更喜欢使用 tbl 和 chr 而不是 1 和 2 来识别我在说什么。

Answer 3

在MySQL 中，您需要将数字ID 设置为PRIMARY KEY，因为AUTO_INCREMENT 可能只是PRIMARY KEY，这意味着它也应该是NOT NULL。

您仍然可以在GUID 列上定义UNIQUE INDEX 并在任何地方使用它，尽管InnoDB 表将聚集在数字id 上，而不是GUID。

Answer 4

有一种观点认为，您永远不应该将您的代理 ID 暴露给外界。所以他们会说，如果你想要一个企业 ID，你应该使用其他东西。

This Wikipedia article，例如，这样说：

分离

生成的代理键的值 - 因为它们是生成的和任意的 - 与 数据的现实意义 连续举行。当检查另一个 持有外键引用的行 代理键，不可能 弄清楚它持有的意义 该参考仅通过查看 行本身的数据。一层是 为每个添加到此间接 必须的外键连接 在尝试制作时导航 数据项的意义。这也可以 使审计更加困难，因为 不正确的数据不明显 检查。

代理键也不自然 用于导出和共享的数据。 一个特别的困难是两个 模式的实例可以保存记录 这在逻辑上意味着同样的事情 （也就是说 - 它们在一个 商业意识），但其中有一个 由于历史不同的关键 键是如何分配的。一个 处理这个问题的方法是 采用代理键为 从未出口或进口：它们是 从未暴露在数据库之外 除了作为瞬态数据（大多数 显然，在执行应用程序时 与 数据库）。

Answer 5

为了更具体地了解您的问题，是的，在数据​​库中使用 GUID 作为主键还有其他问题：

http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx

问题不在于使用 GUID 作为主键，而是使用非顺序 GUID 作为表的聚集索引。

这里的要点是要么使用其他字段作为聚集索引，要么使用顺序 GUID 来避免这种碎片。