sql - 父子关系 : multiple tables vs. 自连接

Question

我正在为一个体育俱乐部开发一个用于统计数据的数据库，我在那里帮助管理一些事件。我想我已经掌握了跟踪竞争对手名称、分类、类别等的部分。使用主表、多个查找表和一对桥接表来计算所涉及的多对多关系。

我为下一部分草拟了一个模型，但我对自己做对了不太满意。我知道我们如何在纸上和/或电子表格中进行操作，我仍在做大量手动工作，但我不是 100% 有信心将其正确“翻译”为表格和关系。

一个简单的事件结构可能是这样的:

Tournament  
- Day 1  
    - Match 1 (Fired Match)  
    - Match 2 (Fired Match)  
    - Match 3 (Fired Match)  
  - Match 4 (Aggregate Match of 1,2,3)  

- Day 2  
    - Match 5 (Fired Match)  
    - Match 6 (Fired Match)  
    - Match 7 (Fired Match)  
  - Match 8 (Aggregate Match of 5,6,7)  

 - Match 9 (Aggregate Match of 4,8)  

我将事情进一步分割，并为“分数”、“阶段”、“比赛”和“锦标赛”(以及其他)制作了表格。这个想法是分数是我需要为每个竞争对手记录的原始数据，外键指向“竞争对手”和“阶段”表。我决定将其视为一个或多个阶段的聚合，而锦标赛可以有一场或多场比赛(聚合)，而不是进行“开火”和“聚合”比赛。

我遗漏了一些由其他外键指示的查找表，因为它们与手头的事情没有直接关系，我猜是“这是解决这个问题的正确方法吗，或者我会更好吗跳过匹配/阶段分离？是否有一种方法可以通过自连接在单个表中重新实现匹配和阶段之间的这种父子关系？

Answer 1

在我看来，它看起来像是一个适当规范化且灵活的层次结构。

按照设计，它意味着一场锦标赛有一场或多场比赛，一场比赛有一个或多个阶段......或者，更重要的是，每个 parent 都有可变数量的 child ， child 的数量总是更大不为零，但可以而且会因实例而异。如果不是这种情况，如果 parent (锦标赛或比赛)总是有相同数量的 child ，那么对数据进行非规范化可能会有一些小优势(比如工作日有七列的表)，但这可能从长远来看会很尴尬。

我绝对不会使用自连接对单个表进行操作，因为层次结构的不同级别包含不同的属性。例如，“Shots”是 Stage 的一部分而不是 Match 的一部分，因此不应成为 Match 表的一部分。