Il y a plusieurs questions/problèmes ici, je vais donc essayer de répondre à chacun.
Toutes les interactions du tournoi doivent être en temps réel/répercutées sur de nombreux utilisateurs.
Pour un trafic faible à moyen sur votre site Web, cela pourrait ne pas être un problème. Pour un trafic plus lourd, cela deviendra rapidement un problème majeur.
Considérez par exemple la fréquence à laquelle vous souhaitez interroger la base de données avec vos appels AJAX. Chaque seconde? Donc si vous avez 100 personnes avec une page ouverte, vous avez 100 appels de base de données chaque seconde ? Vous constaterez que cela tuera rapidement votre base de données.
Même si cela est légèrement hors sujet, je vous recommande fortement de rechercher comment mettre en cache les résultats des tournois à l'avance. Vous pouvez mettre en cache les statistiques, etc. et les laisser expirer ou les faire expirer de manière proactive, mais passez certainement du temps à les rechercher.
Statistiques/résultats en temps réel
Gardez à l'esprit que les jointures prennent du temps dans les bases de données relationnelles. Si vous normalisez fortement la structure de votre tournoi, l'obtention de statistiques peut être pénible. La partie la plus difficile du système à rendre efficace sera les agrégats et les statistiques de chaque tournoi.
Lorsque vous concevez votre base de données/tables/vues/procédures stockées, gardez à l'esprit l'objectif final :obtenir des statistiques rapidement. Cela pourrait signifier pas trop normaliser les données (pour éviter trop de jointures). Cela peut également signifier faire très attention à vos types de données - par exemple en utilisant bits/shorts/etc. au lieu d'entiers.
Comment modéliser les différents types de tournois
Je ne suis pas familier avec les modèles de tournois, mais j'ai des conseils spécifiques sur la façon de modéliser. =)
Quelques questions que vous devriez vous poser :
-
Tous les tournois ont-ils des champs communs ? En d'autres termes, pour un tournoi à la ronde, nous stockons 10 champs. Pour un tournoi à élimination simple, nous stockons 11 champs. S'ils partagent les mêmes 10 champs, je recommanderais de mettre tous les types de tournois dans une seule table, puis d'utiliser un champ tournoi_type pour déterminer le type de tournoi pour votre application.
-
Tous les tournois n'ont-ils pas des champs communs ? Faites-en des tables séparées - une par type de tournoi. Vous pouvez créer un tableau pour les données partagées, mais avoir ensuite différents tableaux pour des informations spécifiques.
-
Les champs du tournoi vont-ils s'éloigner au fil du temps ? Au fil du temps, vous voudrez ajouter des champs aux types de tournois. Si vous prédisez que les tournois deviendront très uniques et très spécifiques au fil du temps, séparez-les. Sinon, vous vous retrouvez avec de nombreux champs contenant des tonnes de valeurs NULL.
-
Avez-vous envisagé une solution NoSQL ? La bonne chose à propos d'un magasin NoSQL est qu'il dénormalise les données afin que vous n'ayez pas de jointures. Vous pouvez également avoir des données hétérogènes (différents types de données) dans la même "table" ou le même conteneur. Juste quelque chose à considérer car cela pourrait vous faciliter considérablement la vie. Découvrez MongoDB comme exemple.
