Hay varias preguntas/problemas aquí, así que intentaré abordar cada uno.
Todas las interacciones del torneo deben ser en tiempo real/reflejadas para muchos usuarios.
Para tráfico pequeño a mediano en su sitio web, esto podría no ser un problema. Para el tráfico más pesado, esto rápidamente comenzará a ser un problema importante.
Considere como ejemplo con qué frecuencia desea sondear la base de datos con sus llamadas AJAX. ¿Cada segundo? Entonces, si tiene 100 personas con una página abierta, ¿tiene 100 llamadas a la base de datos cada segundo? Descubrirá que eso acabará rápidamente con su base de datos.
Aunque esto está un poco fuera de tema, recomiendo investigar cómo almacenar en caché los resultados de los torneos con anticipación. Puede almacenar en caché las estadísticas, etc. y dejar que caduquen o caducar de forma proactiva, pero definitivamente dedique un tiempo a investigarlo.
Estadísticas/resultados en tiempo real
Tenga en cuenta que las uniones toman tiempo en las bases de datos relacionales. Si normaliza mucho la estructura de su torneo, entonces obtener estadísticas puede ser doloroso. La parte más difícil de hacer eficiente del sistema serán los agregados y las estadísticas de cada torneo.
Cuando diseñe su base de datos/tablas/vistas/procedimientos almacenados, tenga en cuenta el objetivo final:obtener estadísticas rápidamente. Esto podría significar no normalizar demasiado los datos (para evitar demasiadas uniones). También podría significar prestar mucha atención a sus tipos de datos, por ejemplo, usar bits/shorts/etc. en lugar de números enteros.
Cómo modelar los diferentes tipos de torneos
No estoy familiarizado con los modelos de torneos, pero tengo consejos específicos sobre cómo modelar. =)
Algunas preguntas que debes hacerte:
-
¿Todos los torneos tienen campos comunes? En otras palabras, para un torneo de todos contra todos almacenamos 10 campos. Para un torneo de eliminación simple almacenamos 11 campos. Si comparten los mismos 10 campos, entonces recomendaría poner todos los tipos de torneos en una tabla y luego usar un campo tipo_torneo para determinar el tipo de torneo para su aplicación.
-
¿No todos los torneos tienen campos comunes? Conviértalas en mesas separadas, una por tipo de torneo. Puede hacer una tabla para datos compartidos, pero luego tener tablas diferentes para información específica.
-
¿Se separarán los campos del torneo con el tiempo ? Con el tiempo querrás agregar campos a los tipos de torneo. Si predice que los torneos se volverán únicos y muy específicos con el tiempo, hágalos separados. De lo contrario, terminará con muchos campos que tienen toneladas de valores NULL en ellos.
-
¿Ha considerado una solución NoSQL ? Lo bueno de una tienda NoSQL es que desnormaliza los datos para que no tenga uniones. También puede tener heterogéneos (diferentes tipos de datos) en la misma "tabla" o contenedor. Solo algo a considerar porque podría hacer su vida considerablemente más fácil. Consulte MongoDB como ejemplo.
