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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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