8

当我需要对用户 ID 进行数值比较时，我应该执行以下操作：

int numeric_user_id = Integer.valueOf("1234343");

还是将其放入长整数或将其保留为整数更好？

谢谢！

4

6 回答 6

9

唯一标识符不应带有任何特殊的语义含义；曾经。UUID 或 GUID 类型仅为实体标识符而设计，因此您不会向它们推断任何语义含义，这就是使它们不透明的原因。

许多实际好处之一是在将数据导入和导出到不同数据库时它们永远不会发生冲突，即；开发、质量保证、生产或在集群中使用时。如果您使用普通的旧数字，尤其是自动递增的数字，每个数据库将有不同的用户使用相同的数字，并且几乎不可能防止欺骗和其他不良数据潜入不同的系统。UUID/GUID 解决方案完全避免了此类问题。

有很多理由不将 id 用于除 id 之外的任何东西。当您拥有超过 30000 个 beta 用户时会发生什么，当您想将某些人踢出 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系统的用户，则按加入日期对它们进行排序并从列表中获取它们的索引

于 2013-01-06T16:28:06.733 回答
3

我建议使用 Long （一个对象，而不是原语），正是因为它允许空值。在对瞬态用户对象（复制、克隆等）进行操作时，您可能会需要这样做。

但是，如果您要将它们保存在数据库中，请使 userId 列不为空（最好将其设为主键）。

使用 Long 而不是 Integer，这样您将来就不必担心溢出。

不要比较 userId 或尝试将它们用于任何逻辑目的（例如找出谁是 beta 用户） - 将它们保留为不透明的标识符。如果您需要知道谁是 beta 用户，请引入数据（例如 accountType）来跟踪它。

正如其他人所提到的，UUID 是另一种完全可以接受的方式，并且具有本质上相当不透明的好处（尽管不完全），几乎强制执行“不解释用户 ID”规则。

于 2013-01-06T16:16:23.027 回答
1

我会说把它变成一个长的原语。原因是，假设您永远不希望它为 null，那么您将永远不会遇到“getUserId()”方法返回 null 用户 ID 并且错误未被捕获的意外情况。

如果将其存储为 long vs. Long 或 Integer，系统会立即将其检测为运行时错误。

如果你将它存储在一个实际的对象中，比如 Long，它可能是 null。如果这是一个错误，您的代码可能会在以后以不可预测的、可能具有破坏性的方式失败。最好尽早发现错误。

如果它可以为 null 并且您使用真实对象，请务必编写代码来处理 null 情况。

至于 int 与 long，您将不得不根据您是否认为它会超过 int 的大小来做出决定。

这也假设您唯一的选择是正常的数字类型。也许还有另一种更适合此类 ID 的数据结构，

于 2013-01-06T15:52:54.810 回答
1

在这种情况下，最好的方法是使用单独的原始类型而不是整数。

于 2013-01-06T16:12:50.053 回答
1

int 的最大值是 2,147,483, 647，超过 20 亿。在大多数情况下， int 应该绰绰有余。

于 2017-08-28T10:06:24.630 回答
0

奇怪的是仍然没有答案主张int。作为自动递增的主键，足以满足 99.99% 的所有应用程序。此外，用户参考资料很多（创建者、最后编辑者……），因此与 long 相比，节省一点是很好的。

如果您有用户注释和其他历史项目等内容，Long 将用作主键。

规则：不久就从int开始，因为对 java 源和数据库的修改很容易。

于 2013-01-06T17:09:07.787 回答