Структура бази даних для гри 2v2

Я регулярно граю у гру 2v2 з 12 друзями і хочу базу даних, щоб відслідковувати гравців, команд, рахунки та ігри, з метою створення системи ранжування.

Оскільки ми регулярно міняємо команди, я складаю таблиці players, teamsі в gamesяких іграх є дві команди (team1 та team2), і команди складаються з двох гравців (player1 та player2).

Це спричиняє досить багато проблем - наприклад, якщо я вибираю двох гравців (назвемо їх A і B ), щоб грати разом, я повинен перевірити, чи вже існує команда, де Player1 - це A, Player2 - B або Player1 - B і Player2 є.

У стовпцях gamesі winsв playersтаблиці та в teamsтаблиці - але це тому, що я хочу бачити, скільки ігор виграють гравці, а також наскільки сумісний гравець у різних командах (як часто гравець виграє, коли поєднується з інший конкретний гравець).

1. Рейтинг табло (я, мабуть, буду використовувати систему оцінювання Elo )
2. Сторінка статистики для кожного гравця з рейтингом, перемогами, іграми, статистикою останніх ігор та з якими гравцями він найбільш сумісний.

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

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

Для першого випуску не існує хитрощів у БД, щоб зробити будь-яке / будь-яке поле складеного ключа обробленим способом АБО, як ви шукаєте, але якщо ваша БД його підтримує, ви можете створити функцію getPlayerTeams(player_id)інкапсуляції запит.

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

Що стосується нормалізації, то розгляньте можливість відокремлення об'єктів від результатів, які виникають, використовуючи team_resultтаблицю для відстеження всіх результатів для даної команди. Трохи більш екстремальна нормалізація також вимагатиме створення player_rating_histтаблиці, що містить усі зміни рейтингу для гравця. Їх поточний рейтинг - це просто той, у кого найновіша дата. Вигляд гравця також може бути використаний, щоб містити останнє значення для легкого запиту.

Запропонована схема (вибачте, без діаграми):

player
    id
    name
    created_on
    updated_on

player_rating_hist
    player_id (FK)
    rating
    rating_date

team
    id
    player1_id (FK)
    player2_id (FK)
    created_on
    updated_on

game
    id
    team1_id (FK)
    team2_id (FK)

team_game
    team_id (FK)
    game_id (FK)
    result
    score
    rating_change

team_rating_hist
    team_id (FK)
    rating
    rating_date

Запити:

--Results for the game, should only ever be two rows for any given game
SELECT * FROM team_game WHERE game_id = 101

--All results for a team
SELECT * FROM team_game WHERE team_id = 123456 

Ця структура дозволяє відокремлювати "базові" об'єкти (гравці та команди) від "контенту", який виникає в результаті роботи системи з часом, і означає, що ви не постійно оновлюєте одну з базових таблиць з поточним рейтингом, # виграшів і т. д. Ці отримані значення і їх слід отримати, отримавши найновіший рейтинг, середній рейтинг, COUNTвиграшів або програшів і т. д. Якщо система отримала достатньо велику кількість, ви можете розглянути можливість вилучення таких сукупних даних в окремий "склад" (навіть якщо це був лише окремий набір таблиць в одній БД) для полегшення аналізу.