多租户数据库中的复合键答案

【问题标题】：Composite keys in a Multi-tenant database多租户数据库中的复合键
【发布时间】：2011-07-20 13:44:48
【问题描述】：

我正在为纯多租户（一个数据库，一个架构）设计一个数据库，我想在我的大多数表中保留一个 Tenant_Id 作为一种安全措施，以确保数据不会出错租客的手。似乎这需要在每个表上都有一个复合键。

例子：

在单租户情况下，我会有一个主键：

Animal_Id (PK)  
Animal_Type  
Animal_Name

在多租户情况下，我会为Tenant_Id添加另一个主键：

Animal_Id (PK)  
Tenant_Id (PK)  
Animal_Type  
Animal_Name

向每个表添加一个 Tenant_Id 列是否意味着我需要在每个表中都有一个复合键，或者有没有一种安全的方法可以避免这种情况？复合键没问题，但如果可以的话，我想避免使用它们。

【问题讨论】：

您说，“我想在我的大多数表中保留一个 Tenant_Id 作为一种安全措施，以确保数据不会落入错误的租户手中。”您如何期望一个tenant_id 列来防止数据落入错误的租户手中？
@Catcall：通过过滤tenant_id?
@Quassnoi：仅当您在数据库的整个生命周期中每个单元都没有超过一个租户时才有效。赔率不好。
@Catcall：多租户数据库的目标是每个单元有一个租户。

【解决方案1】：

除非您为每个客户重复另一个 id（您可能有两个或多个 animal_id = 1），否则没有真正的理由将其设为复合键。您只需添加字段即可。这对我们有用。

【讨论】：

【解决方案2】：

您真的需要支持两个具有相同ANIMAL_ID 值的不同租户吗？无论您使用何种机制来生成看似合成的主键值，都应该能够生成跨租户唯一的值。将TENANT_ID 列添加到表中可能有意义，但将其添加到主键中并不明显。

【讨论】：

酷。也许我把事情复杂化了。谢谢大家。
为什么我们不添加 GUID 作为每条记录的标识符？而不是自动递增的 id
@Murali - 这当然是一个选择。但是，一般而言，生成 GUID 比从序列中获取 nextval 慢，并且需要更多空间来存储数据。它还可以使支持系统变得更具挑战性 - 如果您正在追踪数据中的问题，很容易告诉某人查看ANIMAL_ID 4227。发送 16 字节 RAW 值的 32 个字符的十六进制表示并确保其他人正在查看正确的行会更难。
谢谢贾斯汀！你能看看我的问题stackoverflow.com/questions/12911357/…，如果可能的话，添加你的建议吗？您的意见总是有用的

【解决方案3】：

如果您的所有 id 都是自动递增的整数，您可以添加不是主键一部分的 tenant_id，然后在所有查询中检查它。

但是，这有几个副作用，您可能认为也可能不认为是缺点：

您可以在多对多链接表中链接来自不同租户的两个实体，FOREIGN KEY 约束不会阻止您执行此操作（如果tenant_id 是@ 的一部分） 987654324@)
您的用户可以根据 ID 评估其他租户的数量
您还必须将实体表加入到只能从多对多链接表中进行的搜索（以检查租户）

换句话说，如果你真的不喜欢实体的组合键，可以设计没有它们的数据库。

【讨论】：