2v2ゲームのデータベース構造

私は定期的に12人の友達と2v2ゲームをプレイしています。ランキングシステムを作成することを目的として、データベースにプレーヤー、チーム、スコア、ゲームを追跡させたいと思っています。

私たちは定期的にチームを変更するので、私はテーブルを作ってみたplayers、teamsそしてgamesゲームは2つのチーム（team1とteam2）を持っているし、チームは2人の選手（player1とplayer2）で構成されています。

これにより、かなりの数の問題が発生します。たとえば、2人のプレーヤー（AとBと呼ぶことにします）を一緒にプレイする場合、プレーヤー1がAでプレーヤー2がBであるか、プレーヤー1がBでプレーヤー2であるチームがすでに存在するかどうかを確認する必要があります。 Aです

列gamesとwinsはplayersテーブルとteamsテーブルの両方にありますが、これは、プレーヤーが勝ったゲームの数だけでなく、プレーヤーがさまざまなチームでどの程度互換性があるか（チームとチームを組んだときにプレーヤーが勝つ頻度）も確認したいためです別の特定のプレーヤー）。

1. ランキングスコアボード（おそらくEloレーティングシステムを使用します）
2. レーティング、勝利、ゲーム、最近のゲーム統計、および彼が最も互換性のあるプレーヤーを含むすべてのプレーヤーの統計ページ。

これの多くはデータベースの正規化のいくつかの原則に違反していると私は強く疑っています。データベース設計を実装する方法としていくつかの提案が気に入っています。

現在のスキーマで見られる2つの問題があります。1つは、テーブルの2つのフィールドをチェックして、複合キーが事実上重複しているかどうかを判断する必要があるという問題です。エンティティ（特に、勝ちますが、プレイヤーの格付けも潜在的に）。

最初の問題については、複合キーのいずれかのフィールドを探しているORの方法で扱うようにするDB内のトリックはありませんが、DBがそれをサポートしている場合は、getPlayerTeams(player_id)カプセル化する関数を作成できますクエリ。

（ソートされたプレーヤーIDのハッシュとして計算されたteam_thumbprintを使用してビューを作成することもできます。これにより、同じ2人のコンボの結果は常に同じサムプリントになりますが、ここでは少し多いかもしれません）。

正規化に関しては、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 

この構造により、「ベース」エンティティ（プレーヤーとチーム）を、システムが長時間実行された結果として発生する「コンテンツ」から分離できます。つまり、現在の評価でベーステーブルの1つを常に更新しているわけではありません。これらは派生値であり、最新の評価、平均評価、勝ち負けなどを取得して取得する必要がありますCOUNT。システムが十分に大きくなった場合は、そのような集計データを別の「倉庫」に抽出することを検討できます。 （同じDB内の別個のテーブルセットであったとしても）分析が容易になります。