使用应用程序 ID 生成器与数据库 ID 生成器

Posted 2023-02-23

【中文标题】使用应用程序 ID 生成器与数据库 ID 生成器

【英文标题】：Using Application Id Generator vs. Database Id Generator

【发布时间】：2010-11-24 07:22:08

【问题描述】：

生成数据库 ID 的最佳策略是什么？使用数据库生成器？使用自定义生成器？各有什么优缺点？

【参考方案1】：

数据库生成器：

很容易确保它是独一无二的 需要额外的往返（您必须回读生成的 ID） 通常很简单（序列） 回滚事务时，序列中可能会出现间隙（感谢Kristen 指出这一点）。

应用 ID 生成器

可以根据需要复杂（例如，您可以根据需要在 ID 中编码对象类型） 很难做到独一无二（除非您使用 UUID） 即使不与 DB 交谈，您也可以分配 ID

[编辑] 由于 UUID 非常昂贵（许多数据库中没有本机支持、索引碎片等），大多数应用程序使用基于数据库的生成器。

【讨论】：

感谢您提供的清单。是否有放置 ID 生成器的最佳实践？ DB Generator 对我来说听起来更容易。

查看我的编辑。除非您编写集群软件，否则生成器通常在数据库中。

我最喜欢这个答案，因为它是一个简单的列表，其中包含您必须考虑的要点。谢谢！

DB 分配 ID 的函数（例如 IDENTITY）可能无法提供连续的数字（例如，如果 INSERT 回滚），这一点有时会被忽略，例如如果用于分配发票编号；当然你可以编写自己的 ID 生成器函数 :)

【参考方案2】：

要记住的另一件事是，并非所有对数据库的插入都来自应用程序。当您获得一个新客户并且必须从他们的上一个供应商迁移 100,000 条记录时，使用应用程序驱动的 guid 真的会伤害您。

【讨论】：

很抱歉，我没有从您的回答中明白这一点。请问有谁可以解惑？

关键是如果您在数据库以外的任何地方生成标识符，您的数据就会面临风险。

+1，根据您的设置以及您与之交互的不同系统的数量，可能无法保证数据库中的所有记录都将在您的应用程序中生成。在未来的某个时候，您可能需要将来自外部源的数据合并为一次性迁移（如 HLGEM 建议的那样）或作为批量加​​载过程的一部分。无论哪种情况，如果您的 ID 来自应用程序内部，则加载这些记录会更加困难。您可以拥有 Web 服务或其他类型的 API，但这会对性能产生影响。

您可能决定应用程序“拥有”数据库，因此如果您想向其中插入任何内容，则需要使用该应用程序。

@TheMuffinMan，如果您需要进行数据导入，那将是一件特别糟糕的事情。我不会一次通过应用程序导入一百万条记录，代价是我的系统会被锁定几天。您的建议对于大多数大型业务应用程序都不实用。您不能也不应该将应用程序用于所有事情的真实原因。

【参考方案3】：

我认为最重要的是，您要选择对您的企业有用的东西作为标识符。例如，DMV 将您的驾照号码直接放在卡上，如果您忘记了钱包并记住了号码，它可以用来验证您的身份（例如，当被警察拦下时）。您不会将 UUID 放在卡片上。

对您的业务隐藏标识符可能会引起很多混乱，因此请选择您不介意告诉客户、客户或业务合作伙伴的内容。我并不是说每个人都应该能够记住它，但如果您正在查看收据（例如），您至少应该能够通过电话向某人朗读它。

当然，性能也有例外，但应谨慎使用，不要与业务可见的标识符混为一谈。

查看我的相关@​​987654321@

【讨论】：

请不要混用业务密钥和技术密钥。标识符是唯一标识对象的技术键（例如外键）。它们与索引配合得很好，它们很小并且以一种或另一种方式保持一致。业务密钥（如许可证号）是您向外部显示的内容，但由于它们不可靠（它们可以以任何方式更改并且它们遵循现实，而不是规则），因此您不能将它们作为主键。想想名字：结婚后你的名字可能会改变。或者，您的数据库中可以有两个出生日期相同的“John Smith”。

@Aaron：“请不要混用业务密钥和技术密钥。”我没有混淆他们，我专门解决了差异。 @Aaron：“有两个出生日期相同的约翰史密斯”这是发明新标识符的商业原因，而不是技术原因。