Лучшая схема для представления баскетбольного турнира NCAA - PullRequest
20 голосов
/ 16 марта 2009

Какая схема базы данных лучше всего подходит для баскетбольного мяча NCAA? Вот ссылка, если вы не знакомы: http://www.cbssports.com/collegebasketball/mayhem/brackets/viewable_men

Я вижу несколько разных способов моделирования этих данных, с одной таблицей, множеством таблиц, жестко запрограммированными столбцами, несколько динамических способов и т. Д. Вам нужен способ смоделировать как исходное место, так и место каждой команды, наряду с каждой игрой и результатом (и, возможно, счетом) каждой. Вам также нужен способ показать, кто на каком этапе турнира играет.

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

Ответы [ 8 ]

10 голосов
/ 24 марта 2009

Естественная склонность - смотреть на скобки в том порядке, в котором играются. Вы читаете традиционную схему снаружи в. Но давайте подумаем об этом наоборот. Каждая игра проводится между двумя командами. Один выигрывает, другой проигрывает.

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

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

Итак, чтобы создать базу данных для моделирования, вам действительно нужны только две сущности: Team и Game. Каждый Game имеет два внешних ключа, которые относятся к другим Game с. Имена не имеют значения, но мы бы смоделировали их как отдельные ключи, чтобы обеспечить требование, чтобы в каждой игре было не более двух предыдущих игр. Давайте назовем их leftGame и rightGame, чтобы соответствовать номенклатуре двоичного дерева. Точно так же у нас должен быть ключ с именем parentGame, который отслеживает обратную связь.

Кроме того, как я уже отмечал ранее, вы можете легко определить команды, которые сталкиваются в каждой игре, посмотрев, кто выиграл в двух предыдущих играх. Так что вам действительно нужно отслеживать победителя в каждой игре. Итак, присвойте сущности Game внешний ключ winner для таблицы Team.

Теперь есть небольшая проблема с посевом кронштейна. То есть моделирование матчей для игр первого раунда. Вы можете смоделировать это, имея Game для каждой команды в общем соревновании, где эта команда является winner и не имеет предыдущих игр.

Итак, общая схема будет:

Game:
    winner: Team
    leftGame: Game
    rightGame: Game
    parentGame: Game
    other attributes as you see fit

Team:
    name
    other attributes as you see fit

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

5 голосов
/ 16 марта 2009

Для СУРБД, я думаю, самый простой подход, который все еще достаточно гибок, чтобы приспособиться к большинству ситуаций, состоит в следующем:

  • Команды имеет [идентификатор команды (PK)] , [имя] , [идентификатор региона (от FK до *) 1012 * Регионы )] , [начальное семя] . У вас будет одна запись для каждой команды. (Таблица регионов представляет собой тривиальную кодовую таблицу, содержащую только четыре записи, по одной для каждой области NCAA, и здесь она не указана.)

  • Участники имеют [идентификатор игры (от FK до Игры )] , [идентификатор команды (от FK до ) Команды )] , [оценка (обнуляемая)] , [результат] . [оценка] является недействительным, чтобы отразить, что команда может быть проиграна. На игру обычно приходится два участника.

  • Игры имеет [идентификатор игры (PK)] , [дата] , [местоположение] . Чтобы узнать, какие команды играли в игру, найдите соответствующий идентификатор игры в таблице участников. (Помните, что может быть более двух команд, если кто-то выбыл или был дисквалифицирован.)

Чтобы установить начальную скобку, совместите соответствующие семена друг с другом. Во время игры обратите внимание, какая команда имеет результат = Победитель для конкретной игры; эта команда сравнивается с победителем другой игры. Заполняйте скобки, пока не останется больше победных команд.

2 голосов
/ 24 марта 2009

Я создал небольшую систему со следующими таблицами:

Игры: GameId, TournId, RoundId, последовательность, дата, VisitorId, VisitorScore, HomeId, HomeScore, WinnerId, WinnerGameId, WinnerHome (бит)

Прогнозы: PredId, UserId, GameId, PredVisitorId, PredHomeId, PredWinnerId

Раунды: RoundId, TournId, RoundNum, Heading1, Heading2

Команды: TeamId, TournId, TeamName, Seed, MoreInfo, Url

Турниры: TournId, TournDesc

Пользователи: TournId, Имя пользователя

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

2 голосов
/ 16 марта 2009

Поскольку вы не указали RDBMS, я собираюсь немного измениться и перейти на подход CouchDB, так как я читал об этом в эти выходные. Вот структура документа, который я придумал для представления игры.

{
  "round" : 1, //The final would be round 5, and I guess Alabama St. vs. Morehead would be 0
  "location" : "Dayton, OH",
  "division": "South",
  "teams" : ["UNC", "Radford"]  //A feature of Couch is that fields like teams don't need a fixed nuber of columns.
  "winner" : "UNC"  //Showing my bias
}

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

1 голос
/ 22 января 2014

Для отслеживания большого количества различных предсказаний в скобках: вы можете использовать 67 бит для отслеживания результатов каждой игры. (т.е. каждая из шестидесяти семи игр, сыгранных в турнире, представлена ​​битом, 1 = «победа команды A», 0 = «победа команды B»). Чтобы отобразить любую заданную скобку, вы можете использовать довольно простую функцию для сопоставления 67 битов с пользовательским интерфейсом. Функция знает названия команд и их начальное местоположение, а затем отслеживает их перемещение через скобки, когда она отслеживает «битборд».

1 голос
/ 25 марта 2009

Предлагаемая модель

Предлагаемая схема ER http://img257.imageshack.us/img257/1464/ncaaer.jpg

Team Table

Все, что нам нужно знать о команде, это имя и семя. Поэтому нам нужна таблица «Team» для хранения начального значения. Единственным подходящим ключом является название команды, поэтому мы будем использовать его в качестве основного для простоты. Названия команд NCAA вряд ли изменятся в течение одного турнира или будут содержать дубликаты, поэтому это должен быть адекватный ключ.

Таблица совпадений

Таблица «MatchUp» может использоваться для объединения команд в каждый из матчей. Внешние ключи (FK1, FK2) для «Команды» обеспечат существование команд, а первичный ключ для этих значений гарантирует, что команды сопоставляются друг с другом только один раз.

Внешний ключ (FK4) для таблицы «Team» из таблицы «MatchUp» будет записывать победителя. По логике вещей, победителем должна быть одна из двух команд, участвующих в матче. Проверочное ограничение по первичному ключу может обеспечить это.

Как только будет определен исход матча, семя Виктора может быть извлечено из таблицы команд, чтобы сравнить его с другим Виктором, чтобы определить последующие совпадения. После этого FK (FK3) к полученному совпадению может быть записано в решающие совпадения, чтобы изобразить ход турнира (хотя эти данные, вероятно, могут быть получены в любое время).

Игровой стол

Я также моделировал игры каждого матча. Игра определяется по совпадению, частью которого она является, и порядковым номером в зависимости от порядка, в котором она проходила во время матча. В играх есть победитель из командного стола (FK2). Оценка также может быть записана в этой таблице.

1 голос
/ 25 марта 2009

4 таблицы:

Команда (Команда, Регион, Семя)

Пользователь (UserId, Email, blablabla)

Кронштейн (BracketId, UserId, Points)

Pick (BracketId, GameId, Team, Points)

В каждой скобке, которую отправляет человек, будет 63 строки в таблице выбора.
После каждой игры вы обновляете таблицу выбора, чтобы набирать очки. Поле очков в этой таблице будет нулевым для игры, в которую еще не играли, 0 для неправильного выбора или положительное число для правильного выбора. GameId - это просто ключ, определяющий, где в скобках этого пользователя идет этот выбор (например: East_Round2_Game2, FinalFour_Game1).

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

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

0 голосов
/ 26 марта 2009

Я использую одну и ту же схему для всех своих баз данных.

t
--------
1 guid PK
2 guid FK
3 bit

Тогда в моем коде:

select [2],[3] from t where [1] = @1

@ 1 - это идентификатор данных, которые я получаю. Затем, если [2] не равно нулю, я снова выбираю, устанавливая @ 1 в [2].

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

...