Właściwa technika przechowywania danych o zdarzeniach użytkowników

Jestem głównie samoukiem, jeśli chodzi o projekty baz danych. Zadaję to pytanie, ponieważ zdecydowałem się na tę wspólną strukturę, ale zastanawiam się, czy jest to najbardziej wydajna, czy też „standardowa w branży” metoda.

Większość baz danych, które projektuję, ma tabelę użytkowników, a następnie aktywność osób jest śledzona w innej tabeli. Rozumiem, że piękno bazy danych polega na tego rodzaju wydajnościach, ale tabela aktywności zbierze wiele wielu zdarzeń dość szybko tylko od każdego użytkownika, który regularnie z niej korzysta, dzięki czemu szybko stanie się ogromną tabelą przy umiarkowanym zużyciu użytkownika. Czy to najlepsza praktyka pozwalająca po prostu rosnąć w ten sposób? A może jest to warstwa tabel lub podział na różne tabele na podstawie dat, liczby użytkowników lub czegoś innego?

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

Chciałbym tylko wiedzieć, gdzie mogę coś poprawić, aby pomóc mi się uczyć.

A może jest to warstwa tabel lub podział na różne tabele na podstawie dat, liczby użytkowników lub czegoś innego?

Warto przyjrzeć się koncepcji „partycjonowania” w bazie danych. Większość RDBMS typu mają pewne wsparcie dla nich (np MySQL , Oracle , SQL Server , postgresql ). Zasadniczo pozwalasz RDBMS obsłużyć proces tworzenia / zarządzania faktem, że każdy miesiąc / rok / cokolwiek jest przechowywane w osobnej tabeli, podczas gdy dostęp do niego kod traktuje jako jedną dużą tabelę.

Możesz podzielić go według nazwy użytkownika, daty lub cokolwiek, co będzie najczęściej używane do uzyskania dostępu do danych. (są zalety / wady, które sprawiają, że jest on zorientowany na użytkownika vs. data-centrid ... ale nie wiem, czy chcesz, żebym się tym zajmował)

Dokonałeś bardzo dobrej obserwacji. Aktywny stół będzie rosnąć szybko i duże. To, co robiłem w przeszłości, to archiwizowanie starszych danych (na przykład starszych niż 14 dni) do tabeli ActivityHistory . Spowoduje to utrzymanie tabeli działań w rozsądnym rozmiarze, a jeśli zajdzie potrzeba przeprowadzenia badań, zawsze możesz spojrzeć wstecz na tabelę ActivityHistory .