多租戶數據庫中的組合鍵

我正在爲純多租戶（一個數據庫，一個模式）設計一個數據庫，並且我希望在我的大多數表中保留一個Tenant_Id作爲安全措施，以確保數據不會落入錯誤的租戶手中。看起來這將需要每個表上的複合鍵。多租戶數據庫中的組合鍵

實施例：

在單租戶情況下，我將有一個單一主鍵：

Animal_Id (PK) 
Animal_Type 
Animal_Name

在多租戶情況下，我想補充另一個主鍵爲Tenant_Id：

Animal_Id (PK) 
Tenant_Id (PK) 
Animal_Type 
Animal_Name

是否爲每個表添加一個Tenant_Id列意味着我需要在每個表中都有一個組合鍵，或者有避免這種情況的安全方法嗎？複合鍵是好的，但我想避免它們，如果我可以。

來源

2011-03-22 Thomas

你說過，「我想在我的大多數表格中保留Tenant_Id作爲安全措施，以確保數據不會落入錯誤的租戶手中。」您如何期待tenant_id專欄防止數據落入錯誤的租戶手中？ – 2011-03-22 15:05:34

@Catcall：通過在tenant_id上過濾？ – Quassnoi 2011-03-22 15:17:59

@Quassnoi：只有在數據庫的生命週期中，您從不擁有每個單元的多個租戶時纔有效。賠率不好。 – 2011-03-22 21:38:43

如果你所有的ID都是自動增加的整數，你可以添加tenant_id這不是主鍵的一部分，只是在你的所有查詢中檢查它。

然而，這有若干副作用，你可能會或可能不會看到的缺點：

你可進行連接兩個來自不同租戶的實體在許多一對多連接表和FOREIGN KEY約束贏得「T阻止你這樣做（因爲它會在情況tenant_id是在PRIMARY KEY的一部分）
您的用戶可以評估有多少其他租戶從ID是有
你將不得不額外加入實體表，只有f才能完成搜索ROM許多一對多連接表（檢查租客）

換句話說，如果你真的不喜歡對實體組合鍵，就可以沒有他們來設計數據庫。

來源

2011-03-22 15:03:38 Quassnoi

除非您重複每個客戶的其他ID（您可以擁有兩個或更多的animal_id = 1），否則沒有真正的理由將其作爲組合鍵。您可以添加該字段。這對我們很有用。

來源

2011-03-22 14:59:54 HLGEM

+1 - 打我吧 – 2011-03-22 15:01:26

您是否真的需要支持兩個具有相同ANIMAL_ID值的不同租戶？無論您使用哪種機制來生成似乎是合成主鍵值的機制，都應該能夠生成在租戶中唯一的值。將TENANT_ID列添加到表中可能會有意義，但將它添加到主鍵中並不明顯。

來源

2011-03-22 15:01:01

很酷。也許我過於複雜的事情。多謝你們。 – Thomas 2011-03-22 15:02:24

爲什麼我們不爲每個記錄添加GUID作爲標識符？而不是自動遞增的ID – 2012-10-16 17:58:19

@Murali - 這當然是一種選擇。但是，一般來說，生成一個GUID比從一個序列中獲取'nextval'要慢，並且需要更多空間來存儲數據。它還可以使支持該系統更具挑戰性 - 如果你正在追蹤數據中的問題，很容易告訴某人查看「ANIMAL_ID」4227。發送16字節RAW值的32個字符的十六進制表示並確保其他人正在查看正確的行更加困難。 – 2012-10-16 18:04:32

多租戶數據庫中的組合鍵

回答

相關問題