Советы по разработке базы данных (конкретный пример - фэнтези-футбол)

Question

У меня есть база данных для соревнований по фэнтези-футболу. Есть три схемы:

• afl (относится к субъектам Австралийской футбольной лиги)
• ddhp (относится к местным фэнтезийным объектам) и
• dbo (для лиц, которые не принадлежат ни одному из них).

Описание сущностей

• Каждый игрок играет за команду AFL (нет необходимости отслеживать это по времени, поэтому я просто записываю текущую команду, за которую играет игрок, и обновляю ее, если игрок меняет клубы).
• Некоторые игроки играют за команду ddhp. Это выражается в Контракте, который имеет FromRound и ToRound, выражая временные границы, в течение которых действует контракт.
• Есть раунды. В принципе нет разницы между раундом afl и ddhp, поэтому есть только один стол.
• Существуют Светильники, которые представляют две команды ddhp, играющие друг против друга в раунде.
• Когда игрок играет в раунде, он записывает статистику.
• Каждый раунд, каждая команда dhhp выбирает из своих контрактных игроков тех, кто будет играть за них в этом раунде. Это представлено RoundPlayers.

Проблема в том, что между RoundPlayers и Stats существует некоторая неловкость. Логически, у RoundPlayer есть строка в статистике, представляющая их игру в этом раунде (если они играли). Это отношение один к одному, но обе таблицы являются необязательными. Игрок не может играть в раунде и поэтому не имеет статистики. Игрок также не может быть выбран в качестве RoundPlayer и поэтому не имеет строки в этой таблице. Один имеет ключ от Round и PlayerId, а другой - от Round и ContractId. Переход от одного к другому немного затруднителен, особенно при попытке использовать ORM (например, Entity Framework 4), поскольку свойства навигации основаны на внешних ключах, в то время как это отношение проходит через промежуточную таблицу (Contract) для получения PlayerId.

Я думал о добавлении ContractId в Stats (если игрок был выбран для игры в этом раунде), но это было неправильно. Я также думал об удалении отношения 1: 1 между Stat и Roundplayer и переносе их на один стол, но это тоже было неправильно.

Буду признателен за любые мысли о том, как улучшить отношения между RoundPlayer и Stat, или даже за идеи, которые могут полностью изменить эту структуру.

Answer 1

Я вижу, это было опубликовано год назад, и вы не получили ответов. Надеюсь, вы уже что-то поняли и не напрасно проверяете Stackoverflow каждый день, чтобы посмотреть, предложит ли кто-нибудь помощь. Но в целях общего обсуждения вот мой ответ:

Мне кажется, что недостаток, и я думаю, вы видите одно и то же, состоит в том, что у вас есть две таблицы, записи которых напрямую связаны друг с другом, и, тем не менее, они имеют совершенно разные ключи.

Насколько я понимаю ваше описание, если есть запись RoundPlayers, всегда будет точно одна запись Stats, и наоборот. В этом случае я думаю, что ответ из учебника:

(а) Объединить два в одну запись. Они всегда идут вместе, почему бы не сделать их одной записью? Основная причина, по которой я НЕ вижу этого, заключается в том, что, возможно, RoundPlayer интересен в других контекстах, чем Stats. То есть RoundPlayer интересен, когда мы планируем, но статистика интересна для долгосрочного накопления производительности игрока.

Или (b) Отбросьте внешние ключи в статистике для команды, игрока и раундов. Вместо этого дайте ему один внешний ключ для RoundPlayer или, возможно, продублируйте ссылки на Contract и Round. Это сделало бы ваши ключи последовательными.

Ссылка на Team мне кажется особенно подозрительной. Не могли бы вы найти команду через игрока? Если игрок переключается на другую команду, следует ли обновить команду в статистике, чтобы она соответствовала? Если это так, это избыточно и создает возможность того, что эти два не синхронизируются. Или Стат остается привязанным к первоначальной Команде? Но какая разница для команды, так как это команда AFL, а не команда DDHP? Возможно, я неправильно понимаю требование. Я ничего не знаю об австралийском футболе. (Это, должно быть, очень сложная игра, так как все игроки должны соревноваться, вися вниз головой со дна мира ...)