实体更新策略答案

【问题标题】：Entity Updating strategy实体更新策略
【发布时间】：2010-10-29 12:01:30
【问题描述】：

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

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

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

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

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

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

想法？

谢谢！

【问题讨论】：

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

【解决方案1】：

我的安全框架方法如下：

为数据库中的任何内容提供一个内部 ID（身份列、序列，无论您的数据库支持什么。Hibernate 中的“本机生成的 id 列”）。最终，您将需要它，并且进行改造需要大量工作。
如果您需要将 ID 交给用户，生成一个随机数，检查它是否尚未使用，将其连接到内部 ID，然后将其交给用户。 永远不要分发内部 ID，并且永远不要使用破解者可以猜到的 ID。

至于部分更新，只有当你有很多具有很多属性的对象时，它们才开始有意义。对于 10 个属性，我会说“premature optimization”。

【讨论】：

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：