Database 在web服务中处理ID的最佳实践是什么？

我们有两个通过web服务进行通信的独立系统。称之为前端和后端。很多处理都涉及到在后端更新列表。例如，前端需要更新特定的人员。目前，我们正在设计后端，在那里我们将决定接口应该是什么。我们将需要实际的数据库ID来更新底层数据库，但我们也看到，向消费者传播数据库ID可能是个坏主意

在强制客户端（即前端）必须将ID发送回web服务以更新特定实体时，有哪些替代方案？我们试图避免使用ID的另一个原因是前端通常会保存这些更改，以便在以后发送。这需要前端将我们的ID保存在他们的系统中，这似乎也是个坏主意

我们考虑了以下几点：

1） 将数据库ID发送回前端；他们必须将这些信息发送回处理更改

2） 将散列ID（基于数据库ID）发送回前端；他们必须将这些信息发送回处理更改

---

3） 不要强迫客户机发送ID，而是让他们发送原始实体和新实体，并“匹配”数据库中的我们的实体。他们的原始实体必须与我们保存的实体匹配。我们还必须定义我们的实体与其新实体之间的匹配

前端的唯一合理方法是以某种方式识别数据库中的人员

匹配完整实体不可靠且不明显；要将散列ID返回到前端，您需要首先从前端接收非散列ID，或者在ID下执行一些可恢复的“散列”（更像“加密”），因此无论如何都会有一些个人标识符

IMHO不管它是一个数据库ID还是可以从中提取ID的某个数据段（加密的数据库ID）。为什么您认为消费者知道数据库ID是个坏主意？只要每个人都属于一个消费者，我看不出有任何问题

如果人员（DB中的对象）和使用者之间存在多对多关系，则可以“加密”（广义上）对象id，以便加密依赖于使用者。例如，在与使用者的通信中，可以使用DB中链接（对象和使用者之间）项的ID

如果向使用者发送ID对您来说似乎是个坏主意，因为使用者可能会逐个枚举所有ID，那么您可以通过使用GUID而不是整数自动递增ID来避免此问题

---

PS：关于您的注释，考虑使用GUID作为对象ID。ID是数据的一部分，而不是模式的一部分，因此，在数据库之间迁移时，它将被保留。这样的ID也不会包含敏感信息，所以向消费者（或其他人）透露ID是完全安全的。如果要防止创建具有相同SSN的两个不同的人，只需在SSN字段中添加一个

UNIQUE

键，但不要将SSN用作ID的一部分，因为这种方法有许多严重的缺点，在我看来，记录的ID不会向任何人传达任何敏感信息。
因此，将数据库ID传输到前端（以及一般情况下）没有问题。
唯一关心的是数据库一致性问题，但我看不到任何问题。
此外，从性能上看，它要好得多，因为您不需要查询数据库的属性来查找数据库id

此外，如果发送id的哈希，则无法从哈希中提取id。
您必须在数据库中找到一个与哈希匹配的id，这在我看来是不好的

因此：

我们还看到了将数据库ID传播给我们的消费者可能是一个挑战 坏主意

---

我看不出来。如果你能解释为什么你认为这是个坏主意，可能会有一场讨论。

yipes-感觉1和2基本上是一样的。另外3-当你“定义”匹配的内容时-几乎可以肯定的是，id是关键。。（或者更难看——为所有东西找到备用键）我们在发送数据库ID时犹豫不决的主要原因是这两个系统在某种程度上耦合在一起。如果我们决定更改数据库，这可能会影响前端。此外，可以想象，如果id是例如自然密钥（例如基于ssn），则id可能包含一些敏感信息。我们努力做到务实，但也遵循最佳实践。感谢您的输入。1）更改数据库不应更改ID。2） ID不应该是自然密钥；如果由于某种原因，SSN将发生变化（例如，客户错误地输入了错误的SSN），或者您需要支持来自其他国家/地区的客户，该怎么办？你从错误的角度看待问题；首先，您实现了错误的数据结构（ID包含敏感信息，并且会因DB返工而发生更改），然后您试图实现某种方式来处理对象，而不知道它们的ID。另一个答案请参见下面我的评论。我的主要论点是，如果数据库ID使用自然密钥，系统的耦合和可能的安全问题。1）如果数据库是SSN，这可能是一个问题。但这是吗？或者我们是在理论上讨论吗？2）关于耦合：如果更改数据库，数据不会被丢弃。您的模式将被迁移到新的数据库。那么您关心的是什么？1）我们在理论上讨论。2） 是的，模式可能会改变，但是让模式和数据库独立发展也不错。即使从非理论的角度来看，这也很常见，因为它们的建模方式不同。数据库已规范化