Java 为什么大多数hibernate应用程序都使用序列生成id？

为什么大多数hibernate应用程序都使用序列生成id

为什么不在@GeneratedValue注释中使用默认的GenerationType=AUTO

---

另外，在我的职业生涯中，我看到每个人都在使用序列，但我不明白为什么他们会为更难部署的解决方案而烦恼（部署说明中总是有序列创建SQL命令）。

至少对于Oracle来说是这样的：一个原因是能够跟踪表中对象的数量（如果没有从表中删除对象，则表特定的序列是好的）。使用GenerationType=AUTO使用全局序列号，这会导致数据库中有多个表时id号出现缺口。

摘自Mike Keith和Merrick Schincario的优秀著作

第4章：对象关系映射，节标识符生成

[…]如果应用程序不关心什么 用户使用的生成类型 提供程序，但希望生成 发生时，它可以指定 自动的

使用AUTO有一个陷阱， 但是，提供者可以选择它的 自己存储标识符的策略， 但它需要有某种 要做到这一点，请使用持久性资源。 例如，如果它选择了 基于表的策略，它需要 创建一个表；如果它选择了 基于顺序的策略，它需要 创建序列。提供程序无法 始终依赖于数据库连接 它从服务器获取到 具有在中创建表的权限 数据库。这通常是一个 通常需要的特权操作 仅限于DBA。将需要 是某种创造阶段或阶段 架构生成以导致 自动启动之前要创建的资源 战略能够发挥作用

自动模式真的是一代人 发展战略或 原型设计。它是一种很好的方法 让你站起来跑得更多 当数据库模式被修改时，快速 正在生成。在任何其他 在这种情况下，最好使用 另一种生成策略之一 在后面的章节中讨论[…]

我认为有几个原因：

企业应用程序中使用最多的数据库可能是Oracle，Oracle没有自动生成的ID，而是序列

序列允许在插入新行之前具有ID，而不是插入新行之后。这是更容易使用和更有效的，因为您可以在事务结束时批处理插入语句，但仍然在事务中间定义IDS。

序列允许使用hilo算法（这是hibernate序列生成的默认算法），因此对多个插入只进行一次DB调用，从而提高了性能

自动在数据库之间变化，而序列始终使用相同的策略

选择identity generator有不同的考虑因素，最重要的考虑因素是性能和可移植性，但集群和数据迁移也可能是一个考虑因素。

实际上，在最新的Hibernate版本中（如果不是全部的话），序列策略实际上是基于序列的HiLo，而不是人们必须假设的纯序列。

你可以在我的博客上看到一篇关于身份生成策略的详细文章：

---

Eyal

什么数据库你有针对性吗？自动对MySQL用户来说很常见，但对Oracle或MS来说并不常见。不幸的是，所有的生成策略都有利弊，这就是为什么会有这么多这样的策略的原因。@Will Oracle。我想这背后一定有原因。有趣的观察，我会检查outI是否使用了GenerationType=Auto，我注意到id中的差距连续两行之间