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

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

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

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

Итак, какую модель данных (базу) я должен использовать для такого проекта, который в основном представляет собой электронную таблицу Google Docs, но с предопределенным внешним видом и элементами управления для каждого типа турнира?

Должен ли я выбрать модель, подходящую для всех турниров, или создать отдельные таблицы для всех типов турниров? Любые ресурсы, которые могут быть полезны для такого проекта?


mysql database datamodel data-structures tournament
person user1463028    schedule 26.11.2012    source источник
comment
Когда вы задаете такие вопросы, вы должны четко указать объекты, с которыми должно иметь дело ваше приложение.   -  person SaidbakR    schedule 26.11.2012
comment
Я предполагаю, что вопрос можно свести к следующему: как мне создать структуру базы данных, в которой пользователи могут создавать новые таблицы, в данном случае различные турниры, в которых отслеживаются участники, результаты матчей, турнирная таблица и т. д. Поскольку мой опыт работы с базами данных ограничен парой типов данных в очень статических таблицах, я совершенно не знаю, как подходить к базе данных для такого проекта.   -  person user1463028    schedule 26.11.2012
comment
в этом вопросе слишком мало информации для его сложности. Вы должны указать типы турниров и типы результатов, желательно иллюстрированные в виде таблицы. Людям, которые умеют моделировать, не обязательно знать о турнирах и т. д.   -  person koriander    schedule 15.04.2013

Ответы (1)


arrow_upward
1
arrow_downward

Здесь есть несколько вопросов/проблем, поэтому я постараюсь ответить на каждый из них.

Все взаимодействия в турнирах должны происходить в режиме реального времени/отображаться для многих пользователей.

Для малого и среднего трафика на вашем сайте это может не быть проблемой. Для более интенсивного трафика это быстро станет серьезной проблемой.

В качестве примера рассмотрим, как часто вы хотите опрашивать базу данных с помощью вызовов AJAX. Каждую секунду? Итак, если у вас есть 100 человек с открытой страницей, у вас есть 100 обращений к базе данных каждую секунду? Вы обнаружите, что это быстро убьет вашу базу данных.

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

Статистика/результаты в реальном времени

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

При разработке базы данных/таблиц/представлений/хранимых процедур помните о конечной цели — быстром получении статистики. Это может означать, что не следует нормализовать данные слишком часто (чтобы избежать слишком большого количества объединений). Это также может означать, что нужно уделять очень пристальное внимание вашим типам данных, например, использовать биты/шорты/и т.д. вместо целых чисел.

Как моделировать различные типы турниров

Я не знаком с турнирными моделями, но у меня есть конкретные советы по моделированию. знак равно

Некоторые вопросы, которые вы должны задать себе:

  1. Все ли турниры имеют общие поля? Другими словами, для кругового турнира мы храним 10 полей. Для турнира на выбывание мы храним 11 полей. Если они используют одни и те же 10 полей, то я бы рекомендовал поместить все типы турниров в одну таблицу, а затем использовать поле tour_type, чтобы определить тип турнира для вашего приложения.

  2. Разве у всех турниров нет общих полей? Сделайте для них отдельные таблицы – по одной для каждого типа турнира. Вы можете создать одну таблицу для общих данных, но затем иметь разные таблицы для конкретной информации.

  3. Разрастутся ли турнирные поля со временем? Со временем вы захотите добавить поля к типам турниров. Если вы прогнозируете, что со временем турниры станут очень уникальными и специфическими, сделайте их отдельными. В противном случае вы получите множество полей с множеством значений NULL.

  4. Вы рассматривали решение NoSQL? Хорошая вещь в хранилище NoSQL заключается в том, что он денормализует данные, поэтому у вас нет объединений. Также вы можете иметь разнородные (разные типы данных) в одной и той же «таблице» или контейнере. Просто то, что нужно учитывать, потому что это может значительно облегчить вашу жизнь. Проверьте MongoDB в качестве примера.

person ryan1234    schedule 11.04.2013
comment
И, например, как связать данные каждой лиги с результатами, составами из этого сезона, как смоделировать данные, чтобы, например, получить лучших бомбардиров, почти не убивая базу данных? Должен ли я распространять результаты голов для многих таблиц, относящихся к каждому типу лиг? - person Ivo Pereira; 16.04.2013