实体框架 - 未为继承实体添加外键约束
在我看来，EF4 中的继承实体 (TPT) 出现了一种奇怪的现象。
我有三个实体。 1、资产 2. 财产 3. 活动
属性是资产的派生类型。 属性有很多活动（多对多）
在我的 EDMX 中对此进行建模时，一切看起来都很好，直到我尝试将新属性插入数据库。如果该属性不包含任何活动，它就可以工作，但是当我向新属性添加一些新活动时，一切都会崩溃。
经过 2 天的网络爬行和摆弄后，我注意到在 EF 存储 (SSDL) 中，实体之间的一些约束在更新过程中没有被拾取。
链接属性和活动的Property_Activity表仅显示 一个约束 FK_Property_Activity_Activity 但是 FK_Property_Activity_Property 原为 失踪了。
我知道这是一个实体框架异常，因为当我将数据库中的关系切换为：
Asset <--> Asset_Activity <-->活动
更新后，无论新属性中是否有活动，所有外键约束都会被拾取并且保存成功。
这是有意为之还是 EF 中的错误？
如何解决此问题？
我应该完全放弃继承吗？
It appears to me that a strange phenomenon is occurring with inherited entities (TPT) in EF4.
I have three entities.
1. Asset
2. Property
3. Activity
Property is a derived-type of Asset.
Property has many activities (many-to-many)
When modeling this in my EDMX, everything seems fine until I try to insert a new Property into the database. If the property does not contain any Activity, it works, but all hell breaks loose when I add some new activities to the new Property.
As it turns out after 2 days of crawling the web and fiddling around, I noticed that in the EF store (SSDL) some of the constraints between entities were not picked up during the update process.
Property_Activity table which links properties and activities show only
one constraint
FK_Property_Activity_Activity but
FK_Property_Activity_Property was
missing.
I knew this is an Entity Framework anomoly because when I switched the relationship in the database to:
Asset <--> Asset_Activity <--> Activity
After an update, all foreign key constraints are picked up and the save is successful, with or without activities in the new property.
Is this intended or a bug in EF?
How do I get around this problem?
Should I abandon inheritance altogether?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
基本上我在视觉设计器中使用数据库的更新，但知道设计器有其怪癖。我只是使用数据库的更新来勾勒出我想要的基础知识。然后我自己进入实体 XML 并按照我想要的方式清理它。值得注意的是，复杂类型对于设计者来说是一种痛苦。如果您计划使用复杂类型，请准备好好好学习您的实体 XML。
Basically I use the update from database in the visual designer but knowing that the designer has its quirks. I have simply used the update from database to stub out the basics of what I want. Then I go into the Entity XML my self and clean it up the way I want. Just of note Complex types are a pain with the designer. If you plan to use complex types get ready to learn your Entity XML well.