实体框架和多租户数据库设计 [英] Entity Framework and multi-tenancy database design
问题描述
我正在研究SaaS概念的多租户数据库架构设计.它将是ASP.NET MVC-> EF，但这不是那么重要.
I am looking at multi-tenancy database schema design for an SaaS concept. It will be ASP.NET MVC -> EF, but that isn't so important.
在下面您可以看到一个示例数据库架构(承租人是公司).CompanyId将在整个架构中复制，并且主键已放置在自然键和租户ID上.
Below you can see an example database schema (the Tenant being the Company). The CompanyId is replicated throughout the schema and the primary key has been placed on both the natural key, plus the tenant Id.
将此表放入实体框架时，将表添加到实体模型文件(Model1.edmx)中会出现以下错误:
Plugging this schema into the Entity Framework gives the following errors when I add the tables into the Entity Model file (Model1.edmx):
- 关系"FK_Order_Customer"使用一组外键"{CustomerId，CompanyId}"，这些外键部分包含在表"Order"的一组主键"{OrderId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
- 关系"FK_OrderLine_Customer"使用一组外键"{CustomerId，CompanyId}"，这些外键部分包含在表"OrderLine"的一组主键"{OrderLineId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
- 关系"FK_OrderLine_Order"使用一组外键"{OrderId，CompanyId}"，这些外键部分包含在表"OrderLine"的一组主键"{OrderLineId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
- 关系"FK_Order_Customer"使用一组外键"{CustomerId，CompanyId}"，这些外键部分包含在表"Order"的一组主键"{OrderId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
- 关系"FK_OrderLine_Customer"使用一组外键"{CustomerId，CompanyId}"，这些外键部分包含在表"OrderLine"的一组主键"{OrderLineId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
- 关系"FK_OrderLine_Order"使用一组外键"{OrderId，CompanyId}"，这些外键部分包含在表"OrderLine"的一组主键"{OrderLineId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
- 关系"FK_OrderLine_Product"使用一组外键"{ProductId，CompanyId}"，这些外键部分包含在表"OrderLine"的一组主键"{OrderLineId，CompanyId}"中.外键集必须完全包含在主键集中，或者完全不包含在要映射到模型的主键集中.
问题分为两个部分:
- 我的数据库设计不正确吗?我应该避免使用这些复合主键吗?我对基本模式设计(大脑混乱综合征)提出疑问.请随时提出理想化"方案.
- 或者，如果数据库设计正确，那么EF是否无法匹配密钥，因为EF将这些外键视为潜在的错误配置的1:1关系(不正确)?在哪种情况下，这是EF错误吗?我该如何解决?
推荐答案
在快速扫描EF的错误消息时，它显然不喜欢您设置复合键的方式，而且我认为这可能会误导您正确的方向.再考虑一下什么使您的主键具有唯一性.没有CompanyID的订单ID是否不是唯一的?没有CompanyID的ProductID是否不是唯一的?当然，OrderLine在没有CompanyID的情况下应该是唯一的，因为OrderLine应该仅与单个Order相关联.
On a quick scan of EF's error messages, it clearly doesn't like the way you're setting up compound keys, and I think it's probably nudging you in the right direction. Give some thought again to what makes your primary keys unique. Is the OrderID alone not unique, without a CompanyID? Is a ProductID not unique, without a CompanyID? An OrderLine certainly should be unique without a CompanyID, since an OrderLine should be associated only with a single Order.
如果您确实需要所有这些的CompanyID，这可能意味着所涉及的公司正在向您提供ProductID和OrderID，那么您可能想朝另一个方向发展，并生成自己的非内在主键数据.只需为您的主键设置一个自动增量列，然后将其作为内部OrderID，OrderLineID，ProductID，CompanyID等即可.对该订单的外键引用将是其起点.(而且，CustomerID永远不应是订单行的属性；它是订单的属性，而不是订单行.)
If you truly need the CompanyID for all of these, which probably means that the company in question is supplying you with ProductID and OrderID, then you might want to go a different direction, and generate your own primary keys that are not intrinsic to the data. Simply set up an auto-increment column for your primary key, and let these be the internal OrderID, OrderLineID, ProductID, CompanyID, etc. At that point, the OrderLine won't need the customer's OrderID or CompanyID; the foreign key reference to the Order would be its starting point. (And the CustomerID should never be an attribute of an order line; it's an attribute of the order, not the order line.)
复合键只是一团糟.尝试在没有模型的情况下设计模型，看看它是否可以简化事情.
Compound keys are just messy. Try designing the model without them, and see if it simplifies things.
这篇关于实体框架和多租户数据库设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
