基於租戶的密鑰的常用術語
假設以下架構：
ID | TENANT | TENANT_CUSTOM_ID 346 | 101 | 1 347 | 102 | 1 348 | 101 | 2 349 | 101 | 3 350 | 101 | 4 351 | 102 | 2 352 | 103 | 1**什麼是另一個名稱（或正確的分類）
TENANT_CUSTOM_ID？**也許類似於代理鍵的東西？這個鍵的目的是讓每個租戶都有自己的編號系統，而不是知道他們的記錄與同一張表上的所有其他租戶混合在一起。
自然密鑰（AKA業務密鑰或域密鑰）是用於辨識業務域中資訊的密鑰。
代理項是“看不見”的鍵，位於數據庫內部，無意義且未在業務領域中使用。
真正重要的區別是所討論的屬性是否暴露給使用者/消費者，因此是否具有某些功能並作為現實世界過程的一部分獲得意義。
似乎已經有太多鬆散的術語和與鑰匙相關的民間傳說了。我認為為您在此處所指的那種鍵設置另一個術語不會有幫助。
它絕對不是代理鍵；這是自然的。代理鍵是您添加到數據中的東西。如果它是由客戶提供並特定於他們的數據，那麼它就是您的目的的自然密鑰。
它就像一個UPC或類似的東西。如果這些都沒有意義，那麼出於您的目的，它不需要存在。從架構上講，您可能永遠不會使用它，也永遠不需要它。你也不能隨意改變它。這一切都表明它是自然的。但是，我不會稱它為*“TENANT_CUSTOM_ID”*。我會選擇更正常的東西，比如“ SERIAL_NO ”。這通常是您連結到租戶/供應商/供應商數據庫的方式。
更新，如果你正在生成它。
如果你正在生成它，它是一個代理鍵。第二個代理鍵。但有什麼意義呢？您永遠不應該生成兩個代理鍵。如果您只需要隱藏自己的主鍵，請考慮
- 相反，生成單個 UUID，UUID 稍大，但它會為您節省觸發器。
- 雜湊德
如果您不刪除行，請考慮使用帶有
row_number() OVER (PARTITION BY tenant ORDER BY id).如果您絕對必須擁有特定於租戶的 id，我會進一步建議您放棄正常
id並使用複合鍵tenant, tenant_custom_id。你也可以讓它對系統至關重要。
_custom_id如果它不是自定義的並且您正在生成它，我也不會呼叫它。最後，我不會擔心在多租戶上使用相同的 pkey。這很正常。
來自維基百科，（帶著一粒鹽）
代理密鑰（或合成密鑰、實體標識符、系統生成的**密鑰、數據庫序列號、無事實密鑰、技術密鑰或任意唯一標識符$$ citation needed $$)**在數據庫中是建模世界中的實體或數據庫中的對象的唯一標識符。與從應用程序數據派生的自然（或業務）密鑰不同，代理鍵不是從應用程序數據派生的。
自然密鑰（也稱為業務密鑰）
$$ 1 $$) 是在關係模型數據庫設計中發現的一種唯一鍵，它**由現實世界中已經存在的屬性組成。**它用於與業務相關的列。$$ 2 $$換句話說，自然鍵是與該行中的屬性具有邏輯關係的候選鍵。自然密鑰有時稱為域密鑰。$$ 3 $$