Tecnica corretta per la memorizzazione dei dati degli eventi degli utenti

Sono principalmente autodidatta quando si tratta di progettare database. Sto ponendo questa domanda perché mi sono basato su questa struttura comune, ma mi chiedo se sia il metodo più efficiente o "standard di settore".

La maggior parte dei database che progetto hanno una tabella utente e quindi un'attività di persone viene tracciata in un'altra tabella. Capisco che la bellezza del database sia quella di avere questo tipo di efficienze, ma la tabella delle attività raccoglierà molti eventi abbastanza rapidamente da ogni utente che lo utilizza regolarmente, diventando così una tabella enorme abbastanza rapidamente con un uso moderato da parte dell'utente. È questa buona pratica lasciarla crescere in questo modo? O è un livello di tabelle o suddivisione in tabelle diverse in base alle date o per quantità di utenti o qualcos'altro?

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

Vorrei solo sapere dove posso migliorare qualsiasi cosa, per aiutarmi a imparare.

O è un livello di tabelle o suddivisione in tabelle diverse in base alle date o per quantità di utenti o qualcos'altro?

Potresti voler esaminare il concetto di "partizionamento" nel tuo database. La maggior parte dei RDBMS ha un supporto per loro (ad es. Mysql , oracle , sql server , postgresql ). Fondamentalmente, lasci che RDBMS gestisca il processo di creazione / gestione del fatto che ogni mese / anno / qualunque cosa sia memorizzata in una tabella separata, mentre il codice che accede ad essa lo considera come una grande tabella.

È possibile partizionarlo per nome utente, data o qualunque cosa verrà utilizzata più frequentemente per accedere ai dati. (ci sono vantaggi / svantaggi di renderlo incentrato sull'utente rispetto alla data centrata ... ma non so se vuoi che mi occupi di tutto ciò)

Hai fatto un'ottima osservazione. La tabella delle attività crescerà rapidamente e in grande. Quello che ho fatto in passato è archiviare i dati più vecchi (diciamo più vecchi di 14 giorni) in una tabella ActivityHistory . In questo modo la tabella delle attività viene mantenuta a dimensioni gestibili e, se è necessario effettuare ricerche, è sempre possibile guardare indietro alla tabella ActivityHistory .