在数据库中创建导航关系是不好的做法吗？答案

【问题标题】：Is creating navigational relationships in database bad practice?在数据库中创建导航关系是不好的做法吗？
【发布时间】：2013-06-17 09:23:47
【问题描述】：

我正在使用 EF4.3/Sql Server 2008 Web。

我尝试创建一个规范化数据库 - 这是其中的一部分：

如您所见，共同因素是它们都通过 BuyerId 链接。在 EF 中，我可以使用“Buyer.MatchBuyer.MatchNodes”等在此结构中导航，但是我想知道纯粹为了进一步简化此导航而创建其他关系是否被认为是不好的做法。

例如，在 BuyerId 上添加 LenderMatchNode 和买方之间的关系。

感谢所有建议。

【问题讨论】：

【解决方案1】：

我会说这在数据库中确实不是一个好主意。如果您使用实体框架，您可以使用“表拆分”来实现相同的功能，而无需使用奇怪的数据库结构。

这是一个很好的教程：

Scott Guthrie 的博客上还有其他内容：

编辑：这是我提到的教程：

您可以检查场景三。我想这就是你所追求的。

编辑：Gert Arnolds 的评论让我重新思考了一下。

可能如下：

买家

BuyerId
Name
Status
BuyerTypeId
RequestClass
AcceptQuota
TierId
Commission

MatchNode

BuyerId
TierId
Enabled
RuleClass

那么，Buyer-MatchNode 的 1:N 和可能是 Buyer 的复合键？

在 EF 中，您可以使用前面提到的表格拆分来提供您正在寻找的导航属性。当然，它可能不会有很大的不同，但我想这取决于你喜欢哪种方法。

【讨论】：

我不认为这与表拆分有关。
@GertArnold 在我看来很像。上面的 4 个表可能是一个表（并且可能应该是）。但是 dotnetnoob 想要拥有简化模型的导航属性。
好点，没注意到。但是，Buyer-MatchBuyer 和 LenderMatchNode-Buyer 仍然可以通过拆分来完成。
Buyer-MatchBuyer 关系被拆分，因为Buyer 对所有买家都是通用的，但MatchBuyer 仅与BuyerType 为“Match”的买家相关。还有一个具有自己独特字段的 CompareBuyer。 MatchBuyer 中的数据受触发器约束。 LenderMatchNode-MatchNode 也是如此。
好吧，不一定建议这是一个好主意，但如果您有多个类型，例如 MatchBuyer、CompareBuyer，那么您可以使用继承来提供单个表但多个不同的实体类型。可以在 MS“Employee Tracker”示例中找到这方面的一个示例。 archive.msdn.microsoft.com/ef4/Release/… 我发现这非常有用，但这又取决于您喜欢如何做事。看起来你最初的问题是关于创建纯粹的导航关系，但实际上它们不止于此。