Teknik yang tepat untuk menyimpan data acara pengguna

Saya sebagian besar otodidak dalam hal desain database. Saya mengajukan pertanyaan ini karena saya telah menetapkan struktur umum ini, tetapi saya bertanya-tanya apakah ini metode yang paling efisien atau 'standar industri'.

Sebagian besar database yang saya desain memiliki tabel pengguna, dan kemudian aktivitas orang dilacak di tabel lain. Saya mengerti bahwa keindahan basis data adalah memiliki efisiensi semacam ini, tetapi tabel aktivitas akan mengumpulkan banyak banyak peristiwa dengan cukup cepat hanya dari setiap pengguna yang menggunakannya secara teratur, sehingga menjadi tabel besar dengan cepat dengan penggunaan pengguna yang moderat. Apakah praktik terbaik ini membiarkannya tumbuh dengan cara ini? Atau apakah tingkatan tabel, atau pemisahan ke tabel yang berbeda berdasarkan tanggal, atau per jumlah pengguna, atau sesuatu yang lain?

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

Saya hanya ingin tahu di mana saya bisa meningkatkan apa pun, untuk membantu saya belajar.

Atau apakah tingkatan tabel, atau pemisahan ke tabel yang berbeda berdasarkan tanggal, atau per jumlah pengguna, atau sesuatu yang lain?

Anda mungkin ingin melihat konsep 'partisi' dalam database Anda. Sebagian besar RDBMSes memiliki beberapa dukungan untuk mereka (misalnya, mysql , oracle , sql server , postgresql ). Pada dasarnya, Anda membiarkan RDBMS menangani proses menciptakan / mengelola fakta bahwa setiap bulan / tahun / apa pun disimpan dalam tabel terpisah, sementara kode yang mengaksesnya memperlakukannya sebagai satu tabel besar.

Anda dapat mempartisi berdasarkan nama pengguna, tanggal, atau apa pun yang akan paling sering digunakan untuk mengakses data. (ada kelebihan / kekurangan membuatnya menjadi user-centric vs date-centrid ... tapi saya tidak tahu apakah Anda ingin saya membahas semua itu)

Anda telah melakukan pengamatan yang sangat baik. The Activity meja akan tumbuh cepat dan besar. Apa yang telah saya lakukan di masa lalu adalah mengarsipkan data lama (misalkan lebih dari 14 hari) ke tabel ActivityHistory . Melakukan hal itu membuat tabel Activity ke ukuran yang dapat dikelola dan jika Anda perlu melakukan riset, Anda selalu dapat melihat kembali tabel ActivityHistory .