Barrapunto

Premature optimization is the root of all evil ;)

...te ahorras la cláusula de JOIN en las consultas. Por otro lado, el que tengas muchas actualizaciones no tiene porqué interferir con las SELECT que hagas.

Creo que te va a dar igual una cosa que otra, pero si cada tabla solo va a tener un estad1 y un estad2 a mi me hace menos daño a la vista tenerlo todo en una sola tabla. Así si ya tienes seleccionada la tabla no tienes que buscar en la otra para modificarla pues ya tienes el registro adecuado seleccionado. Aunque claro no tengo experiencia con MySql ni se como tienes pensado tratarlas para decirte si lo que te estoy diciendo es cierto.

Una cosa que podrías hacer es probar con las 2 configuraciones y un conjunto de casos de ejemplo razonable (incluso aleatorio) y usar un bucle de por ejemplo 10000 iteraciones seguidas de lo que vayas a hacer con las tablas y quedarte con la que mas te haya convencido.

Como nota final puedo contarte que en un sitio donde curraba hace tiempo tenían una base de datos enorme (1Gb en Access97, si ya veis, un suicidio) y llegaron a la conclusión que usando tablas separadas las consultas tardaban más, así que aunque no fuera lo formalmente correcto decidieron tener quince tablas grandes antes que cincuenta pequeñas, aunque claro ahí realmente se escribía poco en comparación con las lecturas.

En resumen haz lo que quieras xD.

¿Paradigma relacional? ¿Ese que dice que todos los campos con la misma identificación unívoca deben estar en la misma tabla?

A mí la cosa me parece clara: la división en dos tablas, en este caso es una decisión de implementación, no de diseño. A nivel relacional puro tiene que haber una única tabla con los dos campos de estadísticas, excepto si son conceptualmente iguales (en cuyo caso sí sería necesario tener dos tablas).