我们有两个独立的系统通过 Web 服务进行通信。称它们为前端和后端。许多处理涉及更新后端的列表。例如，前端需要更新特定的人。目前，我们正在设计后端，我们正在决定界面应该是什么。我们将需要实际的数据库 id 来更新底层数据库，但我们也看到将数据库 id 传播给我们的消费者可能是一个坏主意。
强制客户端（即前端）必须将 id 发送回 Web 服务以更新特定实体有哪些替代方法？我们试图避免使用 id 的另一个原因是前端通常会保存这些更改以供以后发送。这将需要前端将我们的 id 保存在他们的系统中，这似乎也是一个坏主意。
我们考虑了以下几点：
1）将数据库ID发送回前端；他们必须将这些发回以处理更改
2) 将散列 ID（基于数据库 ID）发送回前端；他们必须将这些发回以处理更改。
3）不要强迫客户端发送ID，而是让他们发送原始实体和新实体，并“匹配”到我们在数据库中的实体。他们的原始实体必须与我们保存的实体相匹配。我们还必须定义什么构成了我们的实体和他们的新实体之间的匹配。
The only reasonable way for front-end would be to someway identify persons in DB.
Matching the full entity is unreliable and isn't obvious; for returning hashed ID to front-end you need to receive not-hashed ID from front-end first, or perform some revertible "hashing" (more like "encrypting") under IDs, so anyway there would be some person identifier.
IMHO it does not matter whether it will be a database ID or some piece of data (encrypted database ID) from which the ID could be extracted. Why do you think that consumers knowing the database ID would be a bad idea? I don't see any problem as long as every person belongs to a single consumer.
If there is many-to-many relation between persons (objects in DB) and consumers, then you may "encrypt" (in the broad sense) the object id so that the encryption will be consumer-dependent. For example, in communication with consumer you can use the ID of the link (between object and consumer) entry in DB.
If sending IDs to consumers seems to be the bad idea for you because of the possibility of consumer enumerating all the IDs one-by-one, you can avoid this problem by using GUIDs instead of an integer auto-incremented IDs.
PS: As for your comment, consider using e.g. GUID as an object ID. The ID is the part of data, not the part of schema, so it will be preserved when migrating between databases. Such the ID won't contain sensitive information as well, so it is perfectly safe to reveal the ID to consumer (or someone else). If you want to prevent creation of two different persons with the same SSNs, just add an UNIQUE key on your SSN field, but do not use SSN as the part of ID, as such approach has many serious disadvantages, with inability to reveal the ID being the least of them.
从我的角度来看，记录的 id 不会向任何人传达任何敏感信息。
因此，将数据库 ID 传输到前端（和一般情况下）没有问题。
唯一的担忧与数据库一致性问题有关，但我看不到任何问题。
此外，从性能来看，它要好得多，因为您不需要查询数据库的属性来查找数据库 ID。
此外，如果您发送 id 的散列，则无法从散列中提取 id。
您必须在数据库中找到一个与哈希匹配的 id，这不是很好的 IMO
所以：
我们还看到将数据库 ID 传播给我们的消费者可能是个坏主意。
我没看到。如果你能解释为什么你认为这是一个坏主意，可能会有讨论。