1日1回、地域ランキングと世界ランキングを計算する予定です。複数のランキングがあり、それぞれが評価または統計に基づいています。
これらのプレーヤーのランキングを保存するにはどうすればよいでしょうか? プレイヤー ID、地域ランク、グローバル ランクを各行に含む個々の統計ごとにテーブルを作成するか、多数の列を含む単一のランキング テーブルを作成する方がよいでしょうか? 2 番目のオプションでは、プレイヤーがその特定の統計を持っていない可能性があるため、一部の行に空の列が表示されます。
また、プレーヤーの進行状況を示すグラフを作成できるように、毎日のランキングを保存する最も効率的な方法は何ですか? グラフを作成しないことにした場合は、新しいテーブルを作成する前にテーブルを削除します。
問題は、データの使用方法とパフォーマンス要件に集中しています。
ほぼすべてのプレーヤーがほぼすべての統計情報を持ち、アプリケーションがすべての統計情報を同時に使用している場合、パフォーマンスの観点から考えると簡単です。それらを単一のテーブルに格納したいので、データをまとめるために必要な結合とともに、統計ごとに余分な「playerid」のオーバーヘッドが発生しません。
反対に、ほとんどの統計が空で、アプリケーションが一度に 1 つの統計のみを使用している場合、"playerid"、"statid"、"value" を持つ単一のテーブルが適切なアプローチです。
エンティティ属性値 (EAV) モデルの例である 2 番目のアプローチも、新しい統計を追加する必要がある場合に非常に役立ちます。ただし、すべての値を 1 日に 1 回再作成する必要があり、履歴要件について言及していません。この利点は、あなたの場合には明らかではありません。
個別の値を個別のテーブルに格納するオプションは、特にすべての統計が同じ表現 (つまり 1 つの数値) を持っている場合は、おそらく最善の方法ではありません。一般に、テーブルを増殖させることは悪い考えです。1 つの例外は、アクセス制御に関係しています。統計ごとに個別のセキュリティ要件がある場合は、それらを個別のテーブルに格納すると、セキュリティの実装が容易になる場合があります。
あなたの言うことに基づいて、私は非正規化された、プレーヤーごとに1行で、多くの統計アプローチを使用します。プレーヤーがどのように見えるかを見たいと思うかもしれませんが、非常に多くのプレーヤーまたは非常に多くの統計がない限り、データは追加の処理なしでそこにあります。
Just create one table with a primary key on playerId and date and add a column for each stat. YOu can then easily analyze anything on that table.