我正在使用 EF4.3/Sql Server 2008 Web。
我试图创建一个规范化的数据库 - 这是其中的一部分:
如您所见,共同因素是它们都通过BuyerId 链接。在 EF 中,我可以使用“Buyer.MatchBuyer.MatchNodes”等在此结构中导航,但是我想知道纯粹为了进一步简化此导航而创建其他关系是否被认为是不好的做法。
例如,在买方 ID 上添加 LenderMatchNode 和买方之间的关系。
所有建议表示赞赏。
我正在使用 EF4.3/Sql Server 2008 Web。
我试图创建一个规范化的数据库 - 这是其中的一部分:
如您所见,共同因素是它们都通过BuyerId 链接。在 EF 中,我可以使用“Buyer.MatchBuyer.MatchNodes”等在此结构中导航,但是我想知道纯粹为了进一步简化此导航而创建其他关系是否被认为是不好的做法。
例如,在买方 ID 上添加 LenderMatchNode 和买方之间的关系。
所有建议表示赞赏。
我会说这在数据库中确实不是一个好主意。如果您使用实体框架,您可以使用“表拆分”来实现相同的功能,而无需使用奇怪的数据库结构。
这是一个很好的教程:
Scott Guthrie 的博客上还有其他内容:
http://weblogs.asp.net/scottgu/
编辑:这是我提到的教程:
您可以检查场景三。我想这就是你所追求的。
编辑:Gert Arnolds 的评论让我重新思考了一下。
可能如下:
买方
BuyerId
Name
Status
BuyerTypeId
RequestClass
AcceptQuota
TierId
Commission
匹配节点
BuyerId
TierId
Enabled
RuleClass
那么,Buyer-MatchNode 有 1:N,Buyer-MatchNode 可能有复合键?
在 EF 中,您可以使用上述表格拆分来提供您正在寻找的导航属性。当然,它可能不会有很大的不同,但我想这取决于你喜欢哪种方法。