Técnica adecuada para almacenar datos de eventos de usuarios

Soy principalmente autodidacta cuando se trata de diseños de bases de datos. Estoy planteando esta pregunta porque me he decidido por esta estructura común, pero me pregunto si es el método más eficiente o 'estándar de la industria'.

La mayoría de las bases de datos que diseño tienen una tabla de usuario, y luego una actividad de personas se rastrea en otra tabla. Entiendo que la belleza de la base de datos es tener este tipo de eficiencias, pero la tabla de actividades reunirá muchos eventos con bastante rapidez solo por cada usuario que la use regularmente, convirtiéndose así en una gran tabla con bastante rapidez con un uso moderado del usuario. ¿Es esta la mejor práctica simplemente dejar que crezca de esta manera? ¿O es un nivel de tablas, o dividirse en diferentes tablas en función de las fechas, o por cantidad de usuarios, o algo más?

+--------------------+                   +------------------------+
|   UserData         |                   |   Activity             |
+-=------------------+                   +------------------------+
| ID     (auto uint) | <--1-to-many-+    | ID  (auto uint)        |
| UserName (text)    |              +--> | UserID (uint)          |
| Email    (text)    |                   | Timestamp (time)       |
| additional info... |                   | Type (ID to elsewhere) |
+--------------------+                   | additional info...     | 
                                         +------------------------+

Solo me gustaría saber dónde puedo mejorar cualquier cosa, para ayudarme a aprender.

¿O es un nivel de tablas, o dividirse en diferentes tablas en función de las fechas, o por cantidad de usuarios, o algo más?

Es posible que desee analizar el concepto de "particionamiento" en su base de datos. La mayoría de los RDBMS tienen algún soporte para ellos (por ejemplo, mysql , oracle , sql server , postgresql ). Básicamente, permite que el RDBMS maneje el proceso de crear / administrar el hecho de que cada mes / año / lo que sea que esté almacenado en una tabla separada, mientras que el código de acceso lo trata como una tabla grande.

Puede particionarlo por nombre de usuario, fecha o lo que se vaya a usar con más frecuencia para acceder a los datos. (Hay ventajas / desventajas de hacerlo centrado en el usuario frente a fecha-centrid ... pero no sé si quieres que me ocupe de todo eso)

Has hecho una muy buena observación. La tabla de actividades crecerá rápido y grande. Lo que he hecho en el pasado es archivar los datos más antiguos (por ejemplo, más de 14 días) en una tabla ActivityHistory . Al hacerlo, la tabla de actividades se mantiene en un tamaño manejable y, si necesita hacer una investigación, siempre puede consultar la tabla ActivityHistory .