ここにはいくつかの質問/問題があるので、それぞれに対処しようと思います。
すべてのトーナメントのやりとりはリアルタイムである必要があります/多くのユーザーに反映されます。
Webサイトのトラフィックが中小規模の場合、これは問題にならない可能性があります。交通量が多い場合、これはすぐに大きな問題になり始めます。
例として、AJAX呼び出しを使用してデータベースをポーリングする頻度を考えてみます。一秒ごと？では、ページを開いている人が100人いる場合、毎秒100回のデータベース呼び出しがありますか？これにより、データベースがすぐに停止することがわかります。
これは少し話題から外れていますが、トーナメントの結果を事前にキャッシュする方法を調査することを強くお勧めします。統計などをキャッシュして、期限切れにするか、事前に期限切れにすることができますが、調査には必ず時間をかけます。
リアルタイムの統計/結果
リレーショナルデータベースでは、結合に時間がかかることに注意してください。トーナメント構造を大幅に正規化すると、統計を取得するのが難しい場合があります。システムを効率化するのが最も難しいのは、各トーナメントの集計と統計です。
データベース/テーブル/ビュー/ストアドプロシージャを設計するときは、最終目標である統計情報をすばやく取得することを念頭に置いてください。これは、ではないことを意味する場合があります データの正規化が多すぎます（結合が多すぎないようにするため）。また、データ型に非常に細心の注意を払うことを意味する場合もあります。たとえば、ビット/ショートなどを使用します。整数の代わりに。
さまざまなトーナメントタイプをモデル化する方法
私はトーナメントモデルに精通していませんが、モデル化の方法について具体的なアドバイスがあります。 =）
自問すべきいくつかの質問：
-
すべてのトーナメントに共通のフィールドがありますか？ つまり、ラウンドロビントーナメントでは、10個のフィールドを保存します。ノックアウトトーナメントでは、11のフィールドを保存します。それらが同じ10フィールドを共有している場合は、すべてのトーナメントタイプを1つのテーブルに入れてから、tournament_typeフィールドを使用して、アプリケーションのトーナメントのタイプを決定することをお勧めします。
-
すべてのトーナメントに共通のフィールドがあるわけではありませんか？ それらを別々のテーブルにします-トーナメントタイプごとに1つ。共有データ用に1つのテーブルを作成しても、特定の情報用に別のテーブルを作成する場合があります。
-
トーナメントフィールドは時間の経過とともにバラバラになりますか ？時間の経過とともに、トーナメントタイプにフィールドを追加する必要があります。トーナメントが時間の経過とともに非常にユニークで非常に具体的になると予測する場合は、それらを別々にしてください。そうしないと、大量のNULL値を含むフィールドがたくさんあることになります。
-
NoSQLソリューションを検討しましたか ？ NoSQLストアの良いところは、データを非正規化するため、結合がないことです。また、同じ「テーブル」またはコンテナに異種（異なるタイプのデータ）を含めることもできます。それはあなたの人生をかなり楽にするかもしれないので、考慮すべきことです。例としてMongoDBをチェックしてください。