我对如何在关系数据库结构中表示我的对象有一些误解。
例如，如果我有一个看起来像这样的简单表结构：
如果我基于它生成一个实体框架模型，它看起来像：
如您所见，它是多对多关联。（任何一道菜都含有很多配料，任何配料都可以用在很多菜里）
现在，如果我需要一些额外的参数，比如一道菜中配料的数量，该怎么办？（当然，任何不同菜肴中的每种成分通常都是不同的数字）。
如果我直接向Dish_FooIngridient表中添加一些额外的列，它会破坏自动模型生成的精确性，然后我必须在 EF 模型设计器中手动修复关联，然后使用一些繁琐的查询来操作对象。因为它会生成这样的东西：
如您所见，现在还有其他多余的属性，我不需要。有没有更好的方法来管理它？也许使用复杂的属性或继承的实体，或其他什么？
正如 Apress 的“Entity Framework 4.0 Recipes”中所建议的那样，在没有有效负载的情况下设计多对多关系并不是一个很好的做法。
不幸的是，一个以多个无负载、多对多关系开始的项目通常以多个负载丰富的多对多关系结束。重构模型，特别是在开发周期的后期，以适应多对多关系中的有效负载可能是乏味的。不仅引入了其他实体，而且通过关系的查询和导航模式也发生了变化。一些开发人员认为，每个多对多关系都应该从一些有效载荷开始，通常是合成密钥，因此不可避免地添加更多有效载荷对项目的影响要小得多。所以这是最佳实践。如果您有一个无负载的多对多关系，并且您认为它可能会随着时间的推移而改变以包含负载，从链接表中的额外标识列开始。当您将表导入模型时，您将获得两个一对多的关系，这意味着您编写的代码和您拥有的模型将为随着项目的成熟而出现的任意数量的额外有效负载列做好准备。额外的整数标识列的成本通常是为了保持模型更灵活而付出的很小的代价。
我不明白为什么。将字段添加到 Dish_FoodIngredient 并为其提供主键。将该表添加到您的模型中，就是这样。您可能需要在代码中进行一些重构，但不要为此责怪 EF。
双击您的 Model.edmx 文件，然后在您的对象旁边的空白处，右键单击并单击“从数据库更新模型...”，然后单击完成，它将刷新您的表。