Técnica adequada para armazenar dados de eventos de usuários

Eu sou principalmente autodidata quando se trata de projetos de banco de dados. Estou fazendo essa pergunta porque me decidi por essa estrutura comum, mas estou me perguntando se é o método mais eficiente ou "padrão do setor".

A maioria dos bancos de dados que eu designo possui uma tabela de usuários e, em seguida, uma atividade de pessoas é rastreada em outra tabela. Entendo que a beleza do banco de dados é ter esse tipo de eficiência, mas a tabela de atividades reunirá muitos eventos rapidamente, apenas com todos os usuários que o utilizam regularmente, tornando-se uma tabela enorme rapidamente com o uso moderado do usuário. É uma prática recomendada apenas deixá-lo crescer dessa maneira? Ou existe uma camada de tabelas ou uma divisão em tabelas diferentes com base nas datas, na quantidade de usuários ou em alguma outra coisa?

+--------------------+                   +------------------------+
|   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...     | 
                                         +------------------------+

Eu só gostaria de saber onde posso melhorar qualquer coisa, para me ajudar a aprender.

Ou existe uma camada de tabelas ou uma divisão em tabelas diferentes com base nas datas, na quantidade de usuários ou em alguma outra coisa?

Você pode querer examinar o conceito de 'particionamento' no seu banco de dados. A maioria dos RDBMSs tem algum suporte para eles (por exemplo, mysql , oracle , sql server , postgresql ). Basicamente, você permite que o RDBMS lide com o processo de criação / gerenciamento do fato de que cada mês / ano / o que quer que seja armazenado em uma tabela separada, enquanto o código que o acessa o trata como uma tabela grande.

Você pode particioná-lo por nome de usuário, data ou o que for usado com mais frequência para acessar os dados. (há vantagens / desvantagens de torná-lo centrado no usuário x centrado na data ... mas não sei se você quer que eu entre nisso tudo)

Você fez uma observação muito boa. A tabela Atividade aumentará rapidamente e será grande. O que eu fiz no passado foi arquivar os dados mais antigos (digamos, com mais de 14 dias) em uma tabela ActivityHistory . Isso mantém a tabela Activity em um tamanho gerenciável e, se você precisar fazer pesquisas, poderá sempre olhar para trás na tabela ActivityHistory .