序列生成的主键的正确大小是多少？
目前，我们系统中的主键长度为 10 位数字，刚刚超过了 Java 整数的限制。 我想避免由于这些键中的数字溢出而导致任何维护问题，但同时我不想牺牲太多系统性能来存储我永远不需要的无限大的数字。
您如何管理主键的大小？ 我是否应该坚持使用 Java 整数，以获得相对于较大 Long 的性能优势，并在需要时增加大小，或者我应该硬着头皮，在我的大部分 PK 中使用 Java Long，并且永远不必担心溢出序列大小？
Currently, primary keys in our system are 10 digits longs, just over the limit for Java Integers. I want to avoid any maintenance problems down the road caused by numeric overflow in these keys, but at the same time I do not want to sacrifice much system performance to store infinitely large numbers that I will never need.
How do you handle managing the size of a primary key? Am I better off sticking with Java integers, for the performance benefit over the larger Long, and increasing the size when needed, or should I bite the bullet, go with Java Long for most of my PKs, and never have to worry about overflowing the sequence size?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我总是使用长键（数据库中的数字（18,0）），因为它们只是消除了几乎所有情况下发生这种情况的可能性（极端数据囤积式应用程序除外）。 所有表中的键具有相同的数据类型意味着您可以在父类中的所有模型对象之间共享该字段，并且您的 SQL getter 代码具有一致的代码，等等。
I've always gone with long keys (number(18,0) in database) because they simply remove the possibility of this situation happening in pretty much all situations (extreme data hoarding style applications aside). Having the same data-type across all tables for the key means you can share that field across all of your model objects in a parent class, as well as having consistent code your your SQL getters, and so on.
看起来答案取决于数据溢出 Java 整数的可能性。 如果不了解您的数据是什么，就无法知道这一点。
It seems like the answer depends on how likely you are to overflow the Java integers with your data. And there's no way to know that without some idea of what your data is.
性能优势可以忽略不计，所以我的建议是使用长键。 今后必须处理这个问题可能会是一个大麻烦。
The performance benefit would be negligible, so my advice would be to go with the long keys. Having to deal with that down the road would likely be a major hassle.
这是存储和使用长整数的成本与溢出 32 位整数的可能性之间的平衡。
考虑一个无符号 32 位整数存储超过 40 亿个值。 如果您认为在接下来的 136 年里，该表中每秒平均会生成超过 1 个新行，那么您需要使用 Long。
It's a balance between the cost of storing and using Long integers, versus the likelihood of overflowing a 32-bit integer.
Consider that an unsigned 32-bit integer stores over 4 billion values. If you think you are going to average more than 1 new row every second in this table for the next 136 years, then you need to use a Long.
java中的32位整数是有符号整数，所以只有20亿。 如果由于某种原因，你的SEQUENCE时不时地跳动，那么你的PK之间就会出现一些差距。
使用 long 并没有坏处（请记住，Y2K 问题的发生是因为一些 COBOL 开发人员认为他们会在日期中保存一些字节？）:-)
因此，我总是使用 Long。
32 bit integers in java are signed integers, so only 2 billion. If for some reason, your SEQUENCE keeps jumping now and then, then there will be some gaps between your PKs.
It does NOT hurt to have a long (Remember that the Y2K problem happened because some COBOL developers thought that they will save some bytes in dates ??) :-)
Therefore, I always use Long.