实体更新策略

Question

我的团队正在讨论更新实体数据以及如何最好地处理实体数据。这是一个安全框架，因此这里有一些约束和想法。

1. DB中的每个表都有一个guid的PK，这是我们的多节点集群解决方案所必需的。我们的想法是，我们不希望通过API将实体暴露给客户，因为它可以做两件事，
   1. 向他们提供他们工作所需的更多信息，并向黑客提供有关该系统的更多信息。
   2. 支持噩梦是客户以某种方式对此ID进行硬编码，如果我们需要更改我们的PK，则客户受到影响。

解决方案是公开具有唯一Name的Role对象的项的自然键，以及Realm，保证唯一性，但更新这些值中的任何一个都是挑战，因为您需要指定要更新的旧值和新值，或者在原始对象和新对象中传递两个对象，因此我们可以找到要更新的对象。有点乱，

另一种方法是制作备用密钥并将其暴露给客户端，他们可以随意使用它，我们并不关心因为它与我们的PK无关。

现在似乎每个人都只使用PK作为没有问题的实体的ID，不知道如何让我们的团队在过去很长的编程日中说服他们。

另一个问题是如何支持部分更新，问题是你有10个属性的实体，4个集合等...带有名称+领域组合并指定要更新的属性而不是拉下整个对象更改1字段，发回更新。我说延迟加载集合，但不确定部分更新是否有意义。

想法？

谢谢！

Answer 1

我对安全框架的方法是这样的：

• 在数据库中提供内部ID（标识列，序列，数据库支持的任何内容。“Hibernate中的本机生成的id列”）。最终，你将需要它并且复古是很多工作。

• 如果您需要向用户提供ID，请生成一个随机数，检查它是否已经使用过，将其连接到内部ID，然后将其交给用户。 从不分发内部ID，从不使用可以被破解者猜到的ID。

至于部分更新，如果你有很多具有大量属性的对象，它们才会有意义。对于10个属性，我会说“premature optimization。”

Answer 2

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

您能否提供有关这些部分更新的更多详细信息？我没理解。 ：/

Answer 3

在每个表上使用GUID作为主键听起来像是在寻找麻烦。除非我真的误解你，否则我没有看到这种方法。为什么不向每个用户发出UID并使用UID？

这种方法在所有公司中最为常见。 UID不是PII，因此从安全的角度来看，您可以合法地使用。