Найкращий спосіб розробити базу даних турнірів


13

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

Внизу я створив макет, яким я дуже задоволений, якщо мова йде про збереження результатів усіх "відомих" матчів групового етапу. Цей дизайн дозволяє дуже легко перевірити, чи зробив користувач правильну ставку чи ні.

Але який найкращий спосіб зберігати чверть та півфінал? Ці поєдинки залежать від результатів у груповому етапі.

Один із підходів, про який я думав, - додавати ВСІ матчі до matchesтаблиці, але призначити різні змінні чи ідентифікатори командам господарів / гостям для матчів у фазі вибивання. А потім мати якусь іншу таблицю з тими ідентифікаторами, нанесеними на команди ... Це могло б працювати, але це не так.

Основний дизайн бази даних


Ви вирішили використовувати MySQL або відкриті до альтернатив?
Джек каже, спробуйте topanswers.xyz

Досить сильно вирішено .. Чи є якісь переваги / недоліки з MySQL, про які я повинен знати?
hampusohlsson

Перевірки обмежень не виконуються. Як правило, менше варіантів застосування обмежень за допомогою DRI - але чи важливо це для вас, дуже залежить від вашої програми. Щасливо спілкуватися , якщо ви хочете більше думки :)
говорить Джек намагається topanswers.xyz

Дякую, але я не думаю, що я все-таки використовував би обмеження, оскільки я не дуже знайомий з цим. Буде підтверджено всі дані у моїй програмі до того, як вона буде надіслана до БД, зберігаючи це просто
hampusohlsson

Добре-добре. У БД це звичайно простіше, але це зовсім інша розмова ;)
Джек каже спробувати topanswers.xyz

Відповіді:


3

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

  • дати / місця проведення
  • структура (тобто груповий / вибітний етап)
  • правила (тобто підрахунок очок, правила тай-брейку)

Частина цієї інформації буде даними в таблицях, частина - кодифікованою логікою у видах.

Можливо, щось подібне:

  • команда (team_id, group_code enum ('A', 'B', 'C', 'D'), ім'я)
  • матч (match_id, kickoff_at)
  • group_match (match_id, team_id_home, team_id_away, group_code)
  • knockout_match (match_id, knockout_code enum ('Q1', 'Q2', 'Q3', 'Q4', 'S1', 'S2', 'F')
  • результат (match_id, score_home, score_away)

Таку інформацію, яку команди грають у І кварталі, ніколи не потрібно зберігати безпосередньо, оскільки її можна обчислити з результатів групового етапу. В тільки зміни , щоб зробити , як турнір прогресує є вставляє в resultтаблицю.


3

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

Структура даних виглядає досить міцною, щоб підтримати це. Четверть і півфінал потрібно буде додати до таблиці матчів після того, як результати початкових матчів наводяться. Якщо матчі призначаються випадковим чином, то це ручна операція, однак, якщо вони є в певному порядку ...

   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

... тоді це, можливо, можна зробити за допомогою запиту. Знову ж таки, складність запиту може не вартувати зусиль залежно від кількості команд


1

Хороша ідея зберігати всі сірники в таблиці «сірники». Однак я б додав до нього додаткове поле "рейтинг", оскільки пізніше вам потрібно створити бінарне дерево, щоб ефективно запитувати таблицю в пам'яті. Це класична проблема алгоритму ранжирування, і ви можете знайти Google для турніру сірий код для отримання додаткової інформації або заглянути в мою історію stackoverflow. В основному турнір - це бінарне дерево. Ось хороша стаття про сірі коди: http://villemin.gerard.free.fr/Wwwgvmm/Numerati/CodeGray.htm . На жаль, це французька мова. Ось як генерувати бінарне дерево з рейтингу: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/229068 .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.