设置主键自动递增_反对默认为自动递增主键的参数

设置主键自动递增

实际使用的“ easy”主键已成为年龄的自动递增整数。 插入新记录后，数据库仅增加表的计数器，并将新值用作插入行的主键。 它设置简单，无需维护，并保证可预测的密钥。

出于我自己的目的，我的想法是应该始终使用自动递增的主键。 对于我的许多数据库而言，它们是显而易见的选择，而我从来不需要考虑其他选择。

然后，随着所有分布式幻想的出现，云出现了。

具体来说，我在Google App Engine（GAE）之上启动了一个项目，该应用程序是由每个人都喜欢的搜索怪兽托管的自动缩放应用程序运行时。 App Engine根据称为数据存储区的NoSQL范式提供了分布式云数据库。 您使用Long或String标识符存储对象（在我的情况下为POJO）。 数据存储区是一种强大的功能，可与App Engine的可扩展应用程序运行时架构很好地结合在一起。

我启动了My Gear Pack ，这是一个基于云的Android应用程序和Google Web Toolkit（GWT）客户端，用于帮助精通户外的人们整理装备。 我立即甚至没有考虑，就使用自动生成的Long ID构造了我的所有实体（GAE称之为它们）。 插入新实体后，数据存储区会自动分配一个Long（保证唯一）。

这非常方便，因为我不必管理ID生成代码并处理任何冲突。

然后，用户请求了一项新功能。 他们希望能够使用Android应用程序脱机管理其齿轮列表，而无需建立数据连接。

没问题，我心想！ 我将切断各层，并在其移动设备上创建一个复制的数据库。 我写了很多代码，花了很多时间设计我的宏伟方案，以使用一个空的“ remoteID”字段存储本地实体（在Android中），当它们最终与数据存储区同步时将填充该字段，这将创建真实的Long ID。

这很复杂，我不得不出于沮丧而放弃了几次编码。 我会瞪着我的狗，好像它们对我的虐待一样。 最终跌落到地板上并与他们搏斗使事情变得更好。 它总是使事情变得更好。

解决方案：通用唯一标识符

经过大量的研究和各种可能的解决方案的实验之后，我了解了现代编程语言中被低估的功能之一，即通用唯一标识符 （UUID）。

UUID是纯随机的伪随机生成的128位数字。 由于创建数字时需要考虑多个参数，因此人们普遍认为它是独特的，以至于我们微薄的地球人大脑无法理解生成重复项的方法。

UUID通常表示为十六进制字符串。 因此，我没有使用数据存储区生成的Long ID，而是使用字符串作为实体标识符构建了整个项目堆栈（GAE Java后端，GWT客户端和Android客户端）的原型版本。 当用户想要创建新的齿轮列表或齿轮项目而不连接到数据存储时，这使我的脱机客户端可以生成ID。

事实证明，该解决方案比我预期的要好。 我仍然可以使用复制的数据库设计在客户端和云后端之间来回同步，现在可以唯一地标识数据存储区中任何类型的任何实体。

生活是完美的！ 如果我又挑战了几座山露水，我就无法设计出更好的建筑……

然后我考虑了部署。

如何将所有数据存储区实体（大约10,000个）迁移到使用字符串标识符而不是Long标识符？

参考： Keyhole Software博客上反对我们的JCG合作伙伴 Shannon Griswold将默认值默认为自动递增的主键的论点 。

翻译自: https://www.javacodegeeks.com/2013/08/an-argument-against-defaulting-to-auto-increment-primary-keys.html

设置主键自动递增