Entity framework 主键上的多租户联合设置

Entity framework 主键上的多租户联合设置,entity-framework,multi-tenant,composite-primary-key,clustered-index,sql-azure-federations,Entity Framework,Multi Tenant,Composite Primary Key,Clustered Index,Sql Azure Federations,问题: 对于多租户单共享数据库,是应该将tenantid字段包括在主键中(这将为应用的表创建一个复合键),然后是聚集索引,还是可以将tenantid仅包括在聚集索引中而不是主键的一部分,以支持将来的azure联合可能性 背景/背景: 我不想让联邦(tenantid)成为主键的一部分,因为我将在Web API中使用EF5(甚至是发布的版本)和OData,据我所知,使用复合键在EF和OData库中工作将变得更加困难 我没有明确阅读需要将联邦密钥作为主键的一部分的位置——只读取复合密钥 我将不必联

问题:

对于多租户单共享数据库,是应该将tenantid字段包括在主键中(这将为应用的表创建一个复合键),然后是聚集索引,还是可以将tenantid仅包括在聚集索引中而不是主键的一部分,以支持将来的azure联合可能性


背景/背景:

我不想让联邦(tenantid)成为主键的一部分,因为我将在Web API中使用EF5(甚至是发布的版本)和OData,据我所知,使用复合键在EF和OData库中工作将变得更加困难

我没有明确阅读需要将联邦密钥作为主键的一部分的位置——只读取复合密钥

我将不必联邦成员开始,但如果我需要规模,我希望选择

注意,我将使用guid只是因为联邦将不接受Identity列作为主键(另一个很长的主题,与这个问题无关)


例如:

表:租户 主键:租户ID(GUID) 聚集索引:TenantID

与:

表:客户 主键:CustomerID(GUID) 外键:租户ID(GUID) 聚集索引:客户,租户

或:

表:客户 主键:客户、租户(复合主键)(GUID) 外键:租户ID(GUID) 聚集索引:客户,租户


参考:

以下是摘自

联合表具有以下限制: 联合表的“联合”列只能包含符合联合成员范围“低包含”和“高独占”的数据

联合列的数据类型必须与联合定义中定义的数据类型完全匹配

联合表上的所有唯一索引和聚集索引都必须包含联合列。联合列在索引中的显示顺序可能与联合中的键序号不同

联盟列值不能更新为联盟成员范围之外的值

联合列不能是持久化或非持久化计算列

联合成员中不支持索引视图

联合列不能为空

联邦表上的所有外键约束都需要在外键中以相同的顺序包含引用者和被引用表上的联邦列。引用表不能与联合表具有外键关系。联邦表可以不受限制地与引用表建立外键关系

通常可以删除使用FEDERATED ON子句创建的表。您还可以使用ALTER TABLE更改联邦表的所有属性,但联邦属性(如联邦密钥)除外。要将引用表更改为联合表或将联合表更改为引用表,必须创建具有所需属性的新表并删除现有表

当一个表被标记为STATISTICS_norecomputer时,像SPLIT这样的联合操作不会使统计无效或重新计算统计信息。这可能会在重新分区操作(如拆分)后导致执行计划问题

联合成员不支持identity属性


联邦成员不支持时间戳和rowversion数据类型。

IMHO,使用租户TID是应用程序内部的,用于标识基于租户的数据。下面就足够了

表:客户主键:CustomerID(GUID)外键: 租户ID(GUID)聚集索引:客户,租户ID

我看不到任何有效的理由使tenantid成为复合主键的一部分。此外,通过联邦,我们只识别租户及其数据


因此,您可以将TenantId作为外键/索引。请分享您对此的想法。

我的印象是,在拆分数据库时,您必须在每个表中设置拆分/分片/联邦成员“键”,以便将其带入新形成的数据库中。例如,如果我有一个Customers and Tenants表,并且我想要联合一个租户及其客户,我需要租户(TenantId PK)和客户(CustomerId PK,TenantId PK,FK)表中的租户ID。理解是,当您提供基于租户的碎片时,我们用来标识租户的基表将包含租户数据,分片数据库仍将包含租户。此租户使我们能够区分租户及其可能选择使用相同父数据库而不是自己的子租户。例如:如果租户在美国,则子租户(如CA、NY、WA)可能使用美国租户的共享数据库而不是自己的共享数据库。希望这是清楚的。。。