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

12

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.

database-design database-recommendation

— CenterOrbit
fonte

5

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)

— Joe
fonte

Obrigado @ Joe, eu o li na Wikipedia ( en.wikipedia.org/wiki/Partition_%28database%29 ) e em alguns dos links que você postou. O tipo de particionamento ao qual você se referir seria o particionamento horizontal. Esse é um recurso que eu não sabia que existia até agora. Agora vou fazer uma nova pergunta: dba.stackexchange.com/questions/4134/…, que solicita a prática adequada de particionamento.

— CenterOrbit 26/07

6

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 .

— Michael Riley - também conhecido por Gunny
fonte

1

Gosto da sua ideia e é uma solução que se encaixa em praticamente qualquer configuração de banco de dados, mesmo que não seja compatível com a solução @Joe. No entanto, isso também complicaria algumas das consultas envolvidas se você precisasse acessar os dados arquivados mais antigos e criar a necessidade de adicionar uma união de união. Muito bom, porém, não pensei nessa abordagem. Obrigado.

— CenterOrbit 26/07

Isso não é necessariamente complicado, você pode jogar com as cadeias de conexão do aplicativo para escolher o banco de dados do histórico, caso os dados sejam mais antigos. dias, vá para o servidor vinculado ao arquivo morto em vez do servidor principal.

— Marian

É ainda menos complicado se a tabela ArchiveHistory estiver no mesmo banco de dados.

— Michael Riley - também conhecido como Gunny