问题:
对于 Multi-Tenancy 单共享数据库——tenantid 字段是否应该包含在主键中(这将为应用表创建一个复合键)然后是聚簇索引,或者 tenantid 是否可以只包含在聚簇索引中而不是主键的一部分——以支持 future 的 Azure 联合可能性?
上下文/背景:
我不想让联合 (tenantid) 成为主键的一部分,因为我将使用 EF5(甚至发布的版本)和带有 Web API 的 OData,我的理解是在 EF 和 OData 中工作使用复合键的库将变得更加困难
我没有明确地阅读我需要在哪里使联合键成为主键的一部分——只有复合键
我不需要联合才能开始,但如果我需要扩展,我想要这个选项。
请注意,我将仅使用 GUID,因为联合不会接受身份列作为主键(另一个长主题,与此问题无关)
示例:
表:租户 主键:TenantID (GUID) 聚集索引:TenantID
与:
表:客户 主键:客户 ID (GUID) 外键:TenantID (GUID) 聚簇索引:Customer、TenantID
或者:
表:客户 主键:客户、租户(复合主键)(GUID) 外键:TenantID (GUID) 聚簇索引:Customer、TenantID
引用:
以下摘自Windows Azure Federation Guidelines and Limitations ...联合表具有以下限制: 联邦表的联邦列只能包含向联邦成员确认range_low inclusive和range_high exclusive的数据。
联合列的数据类型必须与联合定义中定义的数据类型完全匹配。
联合表上的所有唯一索引和聚簇索引都必须包含联合列。联合列在索引中出现的顺序可以与联合中的键序号不同。
联合列值不能更新为联合成员范围之外的值。
联合列不能是持久化或非持久化计算列。
联合成员不支持索引 View 。
联合列不能为 NULLable。
联合表的所有外键约束都需要在外键的相同序号处包括引用者表和被引用表上的联合列。引用表不能与联合表有外键关系。联合表可以不受限制地与引用表建立外键关系。
您可以正常删除使用 FEDERATED ON 子句创建的表。您还可以使用 ALTER TABLE 更改联合表的所有属性,但联合属性(例如联合键)除外。要将引用表更改为联合表或将联合表更改为引用表,您必须创建具有所需属性的新表并删除现有表。
当一个表被标记为 STATISTICS_NORECOMPUTE 时,像 SPLIT 这样的联邦操作不会使统计信息失效或重新计算。这可能会在重新分区操作(例如 SPLIT)后导致执行计划问题。
联邦成员不支持身份属性
联邦成员不支持时间戳和行版本数据类型。
最佳答案
恕我直言,在应用程序内部使用 Tenantid 来识别基于租户的数据。以下内容就足够了
Table: Customer Primary Key(s): CustomerID (GUID) Foreign Key(s): TenantID (GUID) Clustered Index: Customer, TenantID
我没有看到任何有效的理由让 tenantid 成为复合主键的一部分。此外,通过联合,我们只识别租户及其数据。
因此,您可以很好地将 TenantId 作为外键/索引。请分享您对此的看法。
关于entity-framework - 主键上的 Multi-Tenancy 联合,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17726128/