如何在多租户数据库中处理 ClientId答案

【问题标题】：How to handle ClientId in multi-tenant database如何在多租户数据库中处理 ClientId
【发布时间】：2013-07-14 06:14:59
【问题描述】：

我有一个多租户数据库，在客户端之间进行严格和关键的数据分离。在将其投入生产之前，我想知道我的方法是否有意义或可能导致问题（安全/性能/维护）。以下2个模型是典型场景：

public class Car
{
    [Key, Column(Order=0)]
    public int carId {get;set;}

    [Key, Column(Order=1)]
    public int clientId {get;set;}

    ...

    public virtual ICollection<Component> components {get;set;}
}

public class Component
{
    [Key, Column(Order=0)]
    public int componentId {get;set;}

    [Key, Column(Order=1)]
    public int clientId {get;set;}

    ...

    [ForeignKey("carId, clientId")]
    public Car car {get;set;}
    public int carId {get;set}
}

这样，每个模型都将 clientId 作为主键，强制它与 .Find() 一起使用，并强制它进入多对多关系的连接表。这意味着存在相当多的冗余，并且当查询实际上对数据分离非常安全时使用 clientId。

将 clientId 强制放入任何内容是否有意义，或者仅将其保留在父模型上是否更好？

【问题讨论】：

clientId 作为主键？还是它的外键？
在上面的代码中，clientId 与实际的 id 属性形成了一个复合键。但这就是我正在努力解决的问题。将其包含在复合 PK 中并将其作为附加的“检查器”强制进入查询中，或者将其保留并仅在父模型上使用。尤其是安全是一个问题。我看不到未来的影响，因为我没有经验。
为什么不使用每个架构的租户？
这是桌面应用程序还是网站？客户端将如何连接到 SQL Server、用户/密码或 Windows 身份验证？
对不起，我错过了，这是一个 API。该数据库由 SimpleMembershipProvider 以及客户端的一般数据使用。我会排除每个模式的租户，因为服务的数据大小（每个客户端相对较小）和成本结构使得多租户方法更可行，在维护和部署方面也是如此。

标签： c# sql-server entity-framework database-design architecture

【解决方案1】：

我认为这是正确的方法。我们只在专利表上与客户一起设计，并且已经开始将其非规范化为各种子表。这意味着它可以用于从子表驱动的查询中。它还允许我们按客户端对表进行分区。

【讨论】：

【解决方案2】：

如果我正在设计这个，我会确保操作数据库的应用程序代码经过全面测试并以高质量编写，而不是以这种方式添加冗余。

以这种方式添加冗余将使您的代码和数据库更难管理，我猜它也会导致性能问题（我没有足够的细节来做出坚定的声明，但看起来确实如此）。

【讨论】：

这里的冗余是所有子表上的一个额外的整数字段以及连接表上的2个额外的整数。所以它仍然是可管理的，但它就在那里。