数据库设计建议（具体示例 - 梦幻足球）

Question

我有一个梦幻足球比赛的数据库。 有三种模式：

• afl（与澳大利亚足球联盟实体有关）
• ddhp（与当地幻想竞赛实体有关）和
• dbo（对于非两者都没有的实体）。

实体描述

• 每个玩家都参加AFL团队（没有必要按时间跟踪，所以我只记录玩家所玩的当前团队，如果玩家改变了俱乐部，则更新此。）
• 有些球员为ddhp球队效力。这由具有FromRound和ToRound的合同表示，表示合同有效的时间边界。
• 有回合。 afl和ddhp轮之间基本上没有区别，所以只有一张桌子。
• 有一些赛程，代表两支ddhp队伍在一轮比赛中相互比赛。
• 当玩家进行一轮比赛时，他们会记录统计数据。
• 每轮，每个ddhp团队从他们的签约球员中选择那些将为他们打球的球员。这由RoundPlayers表示。

问题在于RoundPlayers和Stats之间存在一定程度的尴尬。从逻辑上讲，RoundPlayer在Stats中有一行代表他们在那一轮中的比赛（如果他们参加比赛）。这是一对一的关系，但两个表都是可选的。玩家可能无法进行一轮比赛，因此没有统计数据。玩家可能也不会被选为RoundPlayer，因此该表中没有行。一个是Round和PlayerId，另一个是Round和ContractId。从一个导航到另一个有点尴尬，特别是当尝试使用ORM（例如实体框架4），因为导航属性基于外键，而这种关系通过中间表（契约）来获取PlayerId。

我已经考虑过将ContractId添加到Stats（如果玩家被选中参加那一轮比赛）但是感觉不对。我还考虑过删除Stat和Roundplayer之间的一对一关系并将它们移到一张桌子上，但这也感觉不对。

我对如何在RoundPlayer和Stat之间建立更好的关系以及任何可能完全改变这种结构的想法表示赞赏。

Answer 1

我看到这是一年前发布的，你没有答案。希望你现在已经想到了什么，并且每天都不会徒劳地检查Stackoverflow，看看有人会提供帮助。但为了一般性讨论的目的，这是我的答案：

这个漏洞，在我看来，而且我认为你看到同样的事情，就是你有两个表，它们的记录直接相互关联，但它们的键完全不同。

据我了解你的描述，如果有一个RoundPlayers记录，总会有一个匹配的统计记录，反之亦然。在这种情况下，我认为教科书的答案是：

（a）将两者合并为一条记录。他们总是在一起，为什么不把它们作为一个记录呢？我认为不这样做的主要原因是，RoundPlayer可能在不同的上下文中比Stats更有趣。也就是说，RoundPlayer在我们安排时很有意思，但是Stats对于玩家表现的长期积累很有意思。

或（b）将统计数据中的外键丢弃到团队，玩家和回合中。而是给RoundPlayer一个外键，或者复制到Contract和Round的链接。这会使你的密钥保持一致。

与团队的链接对我来说似乎特别可疑。你能不能通过玩家找到球队？如果玩家切换到另一个团队，那么团队中的统计数据是否应该更新以匹配？如果是这样，它是多余的，并且可能导致两者失去同步。或者Stat仍然与原始团队联系在一起？但是团队有什么不同，因为那是一支AFL团队，而不是DDHP团队？也许我误解了一个要求。我对澳大利亚足球一无所知。 （这一定是一场非常艰难的比赛，因为球员们必须在从世界的底部倒挂的同时进行比赛......）