我們有兩個獨立的系統通過Web服務進行通信。稱它們爲前端和後端。許多處理涉及在後端更新列表。例如，前端需要更新特定的人員。目前，我們正在設計後端，我們正在決定接口應該是什麼。我們將需要實際的數據庫ID來更新底層數據庫，但是我們也會看到向客戶傳播數據庫ID的位置可能不太合適。什麼是在Web服務中處理ID的最佳實踐？
強迫客戶端（即前端）必須發送id到Web服務以更新特定實體的一些替代方法是什麼？我們試圖避免ID的另一個原因是前端經常會將這些更改保存在稍後的日期。這需要前端將我們的ID保存在他們的系統中，這似乎也不是一個好主意。
我們曾考慮以下幾點：
1）發送數據庫ID回到前端;他們將不得不發送這些回來處理更改
2）發送散列ID（基於數據庫ID）回到前端;他們將不得不將這些郵件發回來處理更改。
3）不要強迫客戶端發送標識符，而是讓他們發送原始實體和新實體，並將「匹配」發送到數據庫中的實體。他們的原始實體必須與我們保存的實體相匹配。我們還必須確定什麼構成我們的實體與其新實體之間的匹配。
對於前端來說，唯一合理的方法就是在數據庫中識別人員。
匹配完整的實體是不可靠的，並不明顯;爲了將哈希ID返回到前端，您需要首先從前端接收未哈希ID，或者在ID下執行一些可恢復的「哈希」（更像是「加密」），所以無論如何都會有一些人標識符。
恕我直言，無論它將是一個數據庫ID還是某個可從中提取ID的數據（加密數據庫ID）都無關緊要。你爲什麼認爲知道數據庫ID的消費者會是個壞主意？只要每個人都屬於一個消費者，我就沒有看到任何問題。
如果人員（數據庫中的對象）與消費者之間存在多對多關係，那麼您可以「加密」（廣義上）對象ID，以便加密將與消費者相關。例如，在與消費者溝通時，您可以使用DB中鏈接（在對象和消費者之間）條目的ID。
如果由於消費者可能逐個枚舉所有ID而將消息發送給消費者似乎不是個好主意，可以使用GUID而不是整數自動遞增的ID來避免此問題。 PS：關於您的評論，請考慮使用例如GUID作爲對象ID。該ID是數據的一部分，而不是模式的一部分，因此在數據庫之間遷移時將保留該ID。這樣的ID也不會包含敏感信息，所以向消費者（或其他人）透露ID是完全安全的。如果您想阻止創建具有相同SSN的兩個不同人員，只需在您的SSN字段中添加一個UNIQUE密鑰，但不要將SSN用作ID的一部分，因爲此類方法有許多嚴重的缺點，無法顯示ID是他們中最小的。
我們一直猶豫發送數據庫ID的主要原因是它將這兩個系統結合在一起。如果我們決定更改數據庫，這可能會影響前端。另外，可以設想，如果id是例如自然鍵（例如基於ssn），那麼id可以包含一些敏感信息。我們正在努力務實，但也遵循最佳做法。感謝您的意見。 – tjg184 2012-04-18 13:05:36
1）更改數據庫不應更改ID。 2）ID不應該是自然鍵;出於某種原因，如果SSN會改變（例如，客戶錯誤地輸入了錯誤的SSN），或者您需要支持來自其他國家的客戶？你從錯誤的角度看待問題;首先你實現了錯誤的數據結構（帶有包含敏感信息的ID並且隨着DB返工而發生變化），然後你試圖實現某種方式來處理對象而不知道它們的ID。 – penartur 2012-04-19 08:12:47
從我的角度來看，記錄的ID並不會向任何人傳達任何敏感信息。
因此，將數據庫ID發送到前端（以及一般情況）沒有問題。
唯一值得關注的是數據庫一致性問題，但我看不到任何問題。
此外，從性能來看，它好得多，因爲您無需查詢數據庫上的屬性以查找數據庫ID。
此外，如果您發送了ID的散列，則無法從散列中提取ID。
你必須找到在哈希匹配數據庫中的ID，這是不好的IMO
所以：
我們也看到傳播數據庫ID給我們的消費者可能是一個 壞主意。
我看不到它。如果你能解釋爲什麼你認爲這是一個壞主意，可能會有討論。
看到我的意見下面的其他答案。如果數據庫ID使用自然鍵，我的主要觀點是系統和可能的安全問題的耦合。 – tjg184 2012-04-18 13:16:50
1）如果數據庫是一個SSN，這可能是一個問題。但是呢？還是我們在討論theoritically？2）關於耦合：如果你改變數據庫，數據不會被丟棄。你的模式會被遷移到新的數據庫。所以你擔心什麼？ – Jim 2012-04-18 13:27:18
1）我們在理論上談論。 2）是的，架構可能會改變，但是如果架構和數據庫獨立發展，這將是一件好事。即使從非理論的角度來看，這是相當普遍的，它們的建模方式不同。數據庫的規範化與實際模式不同。感謝您的評論。 – tjg184 2012-04-18 13:31:09
yipes - 感覺就像1和2基本一樣。還有3 - 當你'定義'是什麼使比賽 - 這將幾乎肯定是密鑰的ID ..（或醜陋 - 找到備用鑰匙的一切） – Randy 2012-04-18 12:51:00