Лучшая схема для представления NCAA Basketball Bracket

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Итак, чтобы создать базу данных для моделирования, вам действительно нужны только две сущности: Team а также Game, каждый Game имеет два внешних ключа, которые относятся к другим Games. Имена не имеют значения, но мы бы смоделировали их как отдельные ключи, чтобы обеспечить требование, чтобы в каждой игре было не более двух предыдущих игр. Давайте назовем их 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

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

Answer 3

Поскольку вы не указали 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
}

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

Answer 4

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

Игры: GameId, TournId, RoundId, Sequence, Date, 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, UserName

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

Answer 5

4 таблицы:

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

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

Брекет(BracketId, UserId, Points)

Pick(BracketId, GameId, Team, Points)

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

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

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

Answer 6

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

http://img257.imageshack.us/img257/1464/ncaaer.jpg

Team Table

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

Таблица соответствия

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

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

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

Игровой стол

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

Answer 7

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

Answer 8

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

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

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

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

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

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