Родительско-дочерние отношения: несколько таблиц против самостоятельного объединения

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

Для меня это выглядит как правильно нормализованная и гибкая иерархическая структура.

Как и предполагалось, это означает, что в турнире есть один или несколько матчей, а в матче - одна или несколько стадий ... или, что еще важнее, у каждого родителя есть переменное число детей, причем число всегда больше чем ноль, но может и будет варьироваться от экземпляра к экземпляру. Если это не так, если родитель (Турнир или Матч) всегда будет иметь одинаковое количество дочерних элементов, тогда может быть небольшое преимущество в денормализации данных (например, таблица с семью столбцами для рабочих дней), но это может оказаться неловким в долгосрочной перспективе.

Я бы определенно не делал ни одной таблицы с самостоятельным объединением, поскольку разные уровни иерархии содержат разные атрибуты. Например, «Снимки» являются частью этапа, а не частью матча, поэтому их не следует включать в таблицу матчей.