实体更新策略

Question

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

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

解决方案，露出像一个独特的角色名称的对象和领域项目的博物关键，在一起机制保障独特但更新这两个值中是一个挑战，因为你需要指定老和新值更新，或传递原始对象和新对象中的两个对象，以便我们可以找到要更新的对象。有点凌乱，

另一种方法是做一个备用钥匙，并将其暴露给客户，他们可以使用它的所有他们想要的，我们不关心，因为它不绑定到我们的PK。

似乎现在每个人都只是将PK作为身份证用于没有任何问题的实体，不确定如何说服我们的团队从古老的编程日开始。

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

想法？

谢谢！

Answer 1

我的安全框架的做法是这样的：

• 给任何数据库中的内部ID（标识列，序列，无论你的数据库支持在“本地生成的ID列”休眠说）。最终，你会需要它，而且适应性强是很多工作。

• 如果您需要向用户提供一个ID，请生成一个随机数，检查它是否已被使用，将其连接到一个内部ID，然后将其交给用户。 从不发出内部ID和从来没有使用可以被猜饼干猜出的ID。

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

Answer 2

如果您需要将ID公开给客户端，请使用自然键。这不是很容易实现，但这是正确的方法。

您能否提供关于这些部分更新的更多细节？我没有明白。 ：/

Answer 3

在每张表上使用GUID作为主键听起来像是在问问题，除非我真的误解了你，否则我没有看到这种方法在哪里，为什么不直接向每个用户发布UID并使用UID呢？

这种方法是在所有公司最常见的。UID是不是PII所以你好吗法律因为是作为从安全角度来看。