Entity 实体更新策略

在我的团队中，有一些关于更新实体数据以及如何最好地处理它的讨论。这是一个安全框架，下面是一些限制和想法

DB中的每个表都有一个作为guid的PK，这是我们的多节点集群解决方案所必需的。我们的想法是，我们不想通过API在实体上向客户公开这一点，因为它可以做两件事，

向他们提供工作所需的更多信息，并向黑客提供有关系统的更多信息

支持噩梦是客户端以某种方式硬编码到此ID，如果我们需要更改PK，则会影响客户端

解决方案是使用唯一的名称和领域公开项目（如Role object）的自然键，同时保证唯一性。但是，更新这些值中的任何一个都是一个挑战，因为您需要指定要更新的新旧值，或者在原始对象和新对象中传递两个对象，这样我们就可以找到要更新的对象。有点乱

另一种方法是制作一个备用密钥，并将其公开给客户，客户可以随心所欲地使用它，我们不在乎，因为它与我们的PK无关

现在似乎每个人都只是使用PK作为实体的ID，没有任何问题，不知道如何说服我们的团队从过去的编程时代的老手

另一个问题是如何支持部分更新，问题是您有一个具有10个属性、4个集合等的实体。。。使用name+realm组合并指定要更新的属性，而不是下拉整个objectchange1字段，发送回以进行更新。我说延迟加载集合，但不确定部分更新是否有意义

想法

---

谢谢

如果需要向客户端公开id，请使用自然密钥。实现起来并不容易，但这是正确的方法

---

你能提供更多关于这些部分更新的细节吗？我不明白/

我的安全框架方法如下：

• 为数据库中的任何内容提供一个内部ID（标识列、序列，以及您的数据库支持的任何内容）。Hibernate speak中的“本机生成的ID列”。最终，你会需要它，而复古适合是一个很大的工作

• 如果需要将ID交给用户，请生成一个随机数，检查它是否尚未使用，将其连接到内部ID，然后将其交给用户从不分发内部ID，并且从不使用黑客可以猜到的ID

---

至于部分更新，只有当您有许多具有许多属性的对象时，它们才有意义。对于10个属性，我认为“

在每个表上使用guid作为主键听起来像是自找麻烦。除非我真的误解了你，否则我在任何地方都没有看到这种做法。为什么不给每个用户发一个UID并使用它呢

---

这种方法在所有公司中最为常见。UID不是这样，从安全角度看，您在法律上没有问题。

我们必须使用GUID/唯一标识符作为主键，因为我们有一个分布式数据库，并且通过使数据库群集处于活动状态，类似于oracle RAC，但这是使用MS Sql，问题是不支持标识列，因为您可以在任何节点上插入，而且该值可能不是unqiue或已经使用过，只使用GUID要简单得多。