我有一个问题，当我创建一个新实体时，ID序列就像1001,2002,3003，...有时没有像1003这样的规则等等。
我希望每个表都有一个很好的序列：1,2,3,4,5，...
我遇到的问题始于新的1.9.0.0 S＃arp项目。从1.6.0.0开始或从1.6.0.0开始，之后转换为1.9.0.0的项目都可以并且具有良好的顺序。
你知道哪里可能有问题吗？
我觉得某个地方我必须要有一些东西，但我不知道S＃arp这么好，我不知道，哪里可能有问题。
答案 0 :(得分：2)
从它的外观来看，似乎你正在使用POID生成器生成ID。你可以在这篇文章中阅读所有相关内容：http://nhforge.org/blogs/nhibernate/archive/2009/03/20/nhibernate-poid-generators-revealed.aspx
现在从您提供的ID看起来它正在使用HiLo生成器，读取相同的..给你一个它的要点，每个sessionFactory保留一个保留集（可以定义）的ids它可以分配，当它运行所有ID时，它获得一个新的集合，下一个高值存储在同一个dB的表中。因此，每次重新创建sessionFactory时，它都会获得一个新的集合，这就是为什么增量在你的情况下，这个值为1000 ..我在尖锐的架构wiki中找到了对此的引用：https://github.com/sharparchitecture/Sharp-Architecture/wiki/HiLoGenerator看起来像是将它设置为1000 ..
我猜你定义了类似的约定，这就是你看到这个的原因。
答案 1 :(得分：2)
如果您想要一个好的序列，那么我建议您将Id策略更改为标识。然而，这些类型的发电机具有诸如不允许配料和破坏工作单元的缺点。
正如您所指出的，＃arp使用的HILO策略没有上面列出的缺点。然而，一个缺点（实际上它不是一个缺点）是你的Id's不是顺序的（1001,1002,2001,2002,3003等），因为每次会话工厂构建一个新的HI取自hilo表。在您多次构建项目时，这在您的开发机器上更为明显。在生产服务器上，由于会话工厂重建次数较少，因此差距较小。您也可以将lo减少到10而不是100以缩小差距！
IMO内部Id是顺序的并不重要，毕竟它们是内部的吗？此外，如果删除记录，则无论如何都会出现间隙！
如果您的表id依赖于业务逻辑，那么内部id's不是您的答案，可能您需要一个内部ID，然后是一个具有唯一索引的列，用于您的业务逻辑{{1} }。
我会问自己为什么你认为顺序内部Id是重要的？希望你会意识到，如果实际上没有足够的重要性来担心它。