当我需要对用户id进行数值比较时，我是否应该这样做:
int numeric_user_id = Integer.valueOf("1234343");
还是把它放在long类型中，还是把它保存为Integer类型?
谢谢!
唯一标识符不应该带有任何特殊的语义含义; 。UUID或GUID类型只是为实体标识符设计的，因此您不会推断它们的任何语义含义，这就是使它们不透明的原因。
其中一个实际的好处是它们在向不同的数据库导入和导出数据时永远不会发生冲突，ie;开发、qa、生产，或者在集群中使用时。如果使用普通的旧数字，特别是自动递增的数字，每个数据库将有不同的用户使用相同的数字，并且几乎不可能防止复制和其他坏数据潜入不同的系统。UUID/GUID解决方案完全避免了这种问题。
有很多理由不将id用于其他用途id。当你拥有超过30000个测试用户时会发生什么当你想把一些人踢出beta用户时就会发生这种情况程序，当…
?
至于在业务逻辑中使用id，比如标识beta用户，不要使用id，而是使用另一个属性标志来标识它们。你可以有一个布尔标志，或者一个枚举或其他标志，或者甚至结合他们是一个beta用户的事实，当他们加入beta程序时，他们有一个nullable timestamp，这将标记他们，但这可能会因为泄漏问题而变得不那么灵活;但在某些情况下，这可能是合适的。
public interface Identifiable {
public UUID getUUID();
}
public interface BetaUser extends Identifiable {
public boolean isBetaUser();
public Date joinedBetaProgramOn();
}
int、long和其他number类型只能用于数学;不适合与数学无关的身份管理或业务逻辑。
如果您想获得系统的nth用户，那么按连接日期对它们排序，并从列表
我建议使用Long(对象，而不是原语)，正是因为它允许空值。在对临时User对象(复制、克隆等)进行操作时，可能会有这样的情况。
如果您打算在数据库中持久化它们，但是，使userId列不为空(更好的是，使它为主键)。
使用Long而不是Integer，这样以后就不用担心溢出了。
不要比较userid或试图将它们用于任何逻辑目的(例如找出谁是beta用户)-将它们作为不透明的标识符。如果您需要知道谁是测试版用户，请引入数据(例如，accountType)来跟踪该用户。
正如其他人所提到的，UUID是另一种完全可以接受的方式，并且在本质上具有相当不透明的优点(尽管不是完全不透明)，几乎强制执行"不解释userid"规则。
我建议把它放到一个long原语中。原因是，假设您从不希望它为空，就不会出现"getUserId()"方法返回空用户id而未捕获错误的意外情况。
如果你把它存储在long、long或Integer类型中，系统会立即检测到它是一个运行时错误。
如果将存储在实际对象中，如Long，则它可能为空。如果这是一个错误，您的代码可能会在稍后以不可预测的、可能具有破坏性的方式失败。最好尽早发现错误。
如果它可以为null，并且你使用一个真实的对象，一定要编写代码来处理null情况。
至于int vs long，你必须根据你是否认为它会超过int的大小来决定。
这也是假设您唯一的选择是普通的数字类型。也许还有另一种数据结构更适合这样的id，
在这种情况下，最好的方法是使用单独的基本类型而不是整数。
int类型的最大值是2,147,483,647，超过了20亿。在大多数情况下，int应该绰绰有余。
奇怪的是，仍然没有答案主张int。作为自动递增的主键，在99.99%的应用程序中就足够了。此外，用户引用有很多(创建者，最后的编辑器，…)，所以稍微节省一点，而不是很长。
如果你有用户笔记和其他历史项目，那么Long将被用作主键。
规则:在之前，长以int开头，因为修改java源代码和数据库很容易。