为什么大多数休眠应用程序都使用序列来生成ID?

| 为什么大多数休眠应用程序都使用序列来生成ID? 为什么不在@GeneratedValue批注中使用默认的GenerationType = AUTO? 附言在我的职业生涯中,我看到每个人都在使用序列,但是我不明白为什么它们会更麻烦地部署解决方案(在部署说明中总是有序列创建SQL命令)。     
已邀请:
我看到几个原因: 企业应用程序中使用最频繁的数据库可能是Oracle,并且Oracle没有自动生成的ID,但是有序列。 序列允许在插入新行之前而不是在插入新行之后具有ID。这更易于使用,效率更高,因为您可以在事务结束时批处理插入语句,但仍在事务中间定义ID。 序列允许使用hilo算法(这是休眠序列生成时的默认算法),因此仅对多个插入进行一次DB调用,从而提高了性能。 数据库之间的AUTO有所不同,而顺序始终使用相同的策略。     
摘自Mike Keith和Merrick Schincario的著作《 Pro JPA 2 Mastering Java Persistence API Pro JPA 2》。 从第4章:对象关系映射,标识符生成部分。   [...]如果应用程序不在乎   产生了一种   提供者,但希望一代   发生,它可以指定一个策略   汽车。      使用AUTO有一个问题,   虽然。提供者可以选择   自己的标识符存储策略   但是它需要某种   为此,需要持久性资源。   例如,如果它选择一个   基于表的策略,它需要   创建表;如果它选择一个   基于序列的策略,它需要   创建一个序列。提供者不能   总是依靠数据库连接   从服务器获得的   有权在中创建表   数据库。这通常是   通常是特权操作   仅限DBA。有需要   成为某种创造阶段或   模式生成导致   在AUTO之前创建的资源   策略能够起作用。      AUTO模式真的是一代   发展战略或   原型制作。它很好地作为一种手段   起床并运行更多的东西   数据库架构是   正在生成。在任何其他   情况下,最好使用   其他一代策略之一   在后面的章节中讨论[...]     
至少对于Oracle:一个原因是能够跟踪表中的对象数量(如果没有从表中删除任何对象,则表特定的顺序是好的)。使用GenerationType = AUTO使用全局序列号,当数据库中有多个表时,这会导致id编号出现间隙。     
选择身份生成器有很多注意事项,最重要的是性能和可移植性,但是群集和数据迁移也可能是一个考虑因素。 实际上,在最新的Hibernate版本(如果不是全部)中,SEQUENCE策略实际上是基于序列的HiLo,而不是人们必须假设的纯序列。 您可以在我的博客上阅读有关身份生成策略的详细信息:此处 艾尔     

要回复问题请先登录注册