Лучший способ создать базу данных турниров

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

Ниже я создал макет, которым я очень доволен, когда дело доходит до хранения результатов всех «известных» матчей группового этапа. Такой дизайн позволяет легко проверить, правильно ли пользователь сделал ставку или нет.

Но как лучше всего сохранить четвертьфинал и полуфинал? Эти матчи зависят от результата на групповом этапе.

Один из подходов, о котором я подумал, - это добавить ВСЕ совпадения в matchesтаблицу, но назначить разные переменные или идентификаторы командам хозяев / гостей для матчей на этапе выбывания. А затем есть какая-то другая таблица с этими идентификаторами, сопоставленными с командами ... Это может сработать, но не будет правильным.

Базовый дизайн базы данных

mysql database-design

— hampusohlsson
источник

Вы решили использовать MySQL или открыты для альтернатив?

— говорит Джек, попробуйте topanswers.xyz

В значительной степени решен .. Есть ли какие-либо преимущества / недостатки с MySQL, о которых я должен знать?

— hampusohlsson

Проверочные ограничения не применяются. Как правило, меньше возможностей для применения ограничений с помощью DRI - но то, насколько это важно для вас, во многом зависит от вашего приложения. Счастливо общаться , если вы хотите больше мнения :)

— говорит Джек пытается topanswers.xyz

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

— hampusohlsson

Хорошо хорошо. Конечно, в БД все проще, но это совсем другой разговор ;)

— говорит Джек, попробуй topanswers.xyz

Ответы:

Я бы начал с попытки исправить всю предопределенную информацию в самой модели, включая

даты / места
структура (т.е. этапы группы / выбывания)
правила (т.е. начисление очков, правила тай-брейка)

Часть этой информации будет представлять собой данные в таблицах, а часть будет кодифицированной логикой в представлениях.

Возможно, что-то вроде этого:

team (team_id, group_code enum ('A', 'B', 'C', 'D'), имя)
match (match_id, kickoff_at)
group_match (match_id, team_id_home, team_id_away, group_code)
knockout_match (match_id, перечисление knockout_code ('Q1', 'Q2', 'Q3', 'Q4', 'S1', 'S2', 'F')
результат (match_id, score_home, score_away)

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

— Джек говорит, попробуйте topanswers.xyz
источник

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

Структура данных выглядит довольно солидно, чтобы поддержать это. Четвертьфинал и полуфинал должны быть добавлены в таблицу совпадений после того, как будут получены результаты первоначального совпадения. Если совпадения назначаются случайным образом, то это ручная операция, если они находятся в определенном порядке ...

   A
match 1 -----+
   B         A
          match 5 -----+
   C         C         |
match 2 -----+         |
   D                   A
                    match 7
   E                   F
match 3 -----+         |
   F         F         |
          match 6 -----+
   G         G
match 4 -----+
   H

... тогда это может быть сделано с помощью запроса. Опять же, сложность запроса может не стоить усилий, в зависимости от количества команд

— Тево Д
источник

Рекомендуется хранить все совпадения в таблице «совпадения». Однако я бы добавил к нему дополнительное поле «ранжирование», потому что позже оно понадобится вам для создания двоичного дерева для эффективного запроса таблицы в памяти. Это классическая проблема с алгоритмом ранжирования, и вы можете найти дополнительную информацию в турнире «Серый код» или посмотреть мою историю переполнения стека. По сути, турнир - это бинарное дерево. Вот хорошая статья о серых кодах: http://villemin.gerard.free.fr/Wwwgvmm/Numerati/CodeGray.htm . К сожалению, это французский. Вот как сгенерировать двоичное дерево из ранжирования: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/229068 .

— Gigamegs
источник