是手动分配实体的ID一个好主意？

Question

我们正在开发一个系统来替换客户的旧应用程序。

实际上，有许多实体（如商家，推销员，产品等）必须具有手动分配的ID - 因此它们可以与其他现有系统集成。即会计。

我们认为最好的解决方案是让用户在创建实体时手动分配实体ID;我们将建议他下一个可用的ID，用户可以根据需要进行更改。不允许更新！ （muahahaha）

我们很高兴听到你的想法。优点/缺点

提前致谢：）

PD：你知道有关的文件吗？ -Entities和ID -

---

更新

• 我们认为应该有这种情况适用但不适用的情况。所以...
• 此外，在某些情况下，客户端确实希望给定的实体具有他们带来的ID。我认为组织内部代码。

Answer 1

永远不要让用户有权分配或创建基础对象标识符。这些必须是系统维护的。

想象一下，如果用户选择了一个已经在使用的ID，试图弄清楚相关实体实际上与哪个实体相关的噩梦。

相反，您应该拥有系统分配的一些类型的常规实体ID（int，guid，无论如何），并用于指向所有依赖对象的链接。然后有一个“外部”id，用户可以将自己的标识符放入其中。

也许这在某种程度上与外部系统有关，也许不是。重点是，无论他们做什么，你都能保持自己的一致性。

Answer 2

通常做的是指定内部使用的自己的，通常是隐藏的标识符。然后创建第二个标识符，用户可以将其用作单独的数据字段。此外，如果您尝试建议下一个ID，则可能会遇到一些并发问题。

Answer 3

我想这归结为关注问题的分离。如果您已经开发了一年多的应用程序，那么您应该已经知道为什么需要在rdb中使用对象标识符，如果您的用户需要关注自己分配和/或管理底层对象标识符，那么您就会遇到设计问题，而这个问题是您正在将数据访问/存储问题与业务逻辑混合在一起。正如其他人已经说过的最好的方法是拥有两个标识符，一个对用户透明，在应用程序内部使用，另一个用于集成过程。

我在与零售商合作时看到了类似的情况，有一个ID和一个产品的SKU，sku本身可能是我们同时拥有良好设计的ID。