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

11

DB生成：

易确保它的独特
需要额外的往返（你必须阅读生成的ID后面）
通常非常简单（序列）
当事务回滚，差距可能出现在序列中（感谢Kristen指出了这一点）。

的App ID生成

可以像你需要（例如，您可以编码对象类型的ID，如果你想）
很难做出唯一的（除非你使用复杂的UUID）
你甚至可以不说话的DB

[编辑]由于UUID的相当昂贵（在许多数据块，指数fragmenta没有原生支持分配ID重刑等），大多数应用程序使用基于数据库的发电机。

来源

2009-08-31 09:36:04

+0

谢谢你的名单。是否有放置Id Generator的最佳做法？数据库发生器对我来说听起来更容易 – bastianneu 2009-08-31 09:52:45

+0

查看我的编辑。除非您编写集群软件，否则生成器通常位于数据库中。 – 2009-08-31 11:28:23

+0

我最喜欢这个答案，导致它的一个简单的列表，你必须考虑重要的一点。谢谢！ – bastianneu 2009-09-01 08:10:44

8

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

来源

2009-08-31 13:12:05 HLGEM

+0

对不起，我不明白你的答案。任何人都可以清理那个吗？ – bastianneu 2009-08-31 15:42:24

+3

关键是，如果您在数据库之外的任何位置生成标识符，则会使数据处于风险之中。 – HLGEM 2009-08-31 17:50:35

+1

+1，这取决于你的设置以及有多少不同与你互动系统，它可能无法保证所有的在你的数据库中的记录会从你的应用程序中产生。您可能会在将来的某个时间点需要合并来自外部数据源的数据，或者作为一次性迁移（如HLGEM所建议的），或者作为批量加载过程的一部分。无论哪种情况下，如果您的ID来自应用程序中，那么加载这些记录将会困难得多。你可以有一个Web服务或其他类型的API，但这会对性能产生影响。 – 2009-08-31 19:37:05

2

我认为最重要的是你选择一些可以被你的企业有用的标识符。例如，DMV将您的许可证号码放在卡片上，如果您忘记了钱包并记住了该号码，它可以用来验证您的身份（例如，当警察拉过来时）。你不会在卡上放置UUID。

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

当然，性能也有例外，但这些应谨慎使用，不得与业务可见标识符混淆。

查看我的相关blog post

来源

2009-08-31 17:30:54

+0

+1不错的阅读。感谢您的链接 – bastianneu 2009-09-01 08:09:40

+2

请不要混用商业密钥和技术密钥。标识符是唯一标识对象的技术键（例如在外键中）。他们在索引上表现良好，他们很小而且一贯以某种方式。业务键（如车牌号码）是你显示什么到外面，但因为它们是不可靠的（他们可以以任何方式改变，他们遵循的现实，而不是规则），你不能依赖于他们作为主键。想想名字：当你结婚时，你的名字可能会改变。或者您可以在数据库中拥有两个具有相同出生日期的“John Smith”。 – 2009-09-01 10:00:12

+0

@Aaron：“请不要混用商业密钥和技术密钥。”我没有把它们混淆，我专门解决了这个区别。 @Aaron：“有两个约翰史密斯出生日期相同”这是发明新标识符的商业原因，而不是技术原因。 – 2009-09-01 16:43:33

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

回答

相关问题