Правильная техника для хранения пользовательских данных о событиях

Я в основном самоучка, когда дело доходит до дизайна базы данных. Я задаю этот вопрос, потому что я остановился на этой общей структуре, но мне интересно, является ли это наиболее эффективным или «отраслевым стандартом» методом.

У большинства баз данных, которые я проектирую, есть таблица пользователей, а затем активность людей отслеживается в другой таблице. Я понимаю, что красота базы данных заключается в том, что она обеспечивает эффективность такого рода, но таблица активности будет собирать достаточно много событий достаточно быстро от каждого пользователя, регулярно ее использующего, таким образом, превращаясь в огромную таблицу довольно быстро при умеренном использовании пользователями. Это лучшая практика, чтобы просто позволить этому расти таким образом? Или это уровень таблиц, или разделение на разные таблицы по датам, количеству пользователей или что-то еще?

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

Я просто хотел бы знать, где я могу улучшить что угодно, чтобы помочь мне учиться.

Или это уровень таблиц, или разделение на разные таблицы по датам, количеству пользователей или что-то еще?

Возможно, вы захотите изучить концепцию «разбиения» в вашей базе данных. Большинство СУБД имеют некоторую поддержку для них (например, mysql , oracle , sql server , postgresql ). По сути, вы позволяете СУБД обрабатывать процесс создания / управления тем фактом, что каждый месяц / год / все, что хранится в отдельной таблице, в то время как код, обращающийся к ней, обрабатывает ее как одну большую таблицу.

Вы можете разделить его по имени пользователя, дате или тому, что будет использоваться чаще всего для доступа к данным. (есть преимущества / недостатки в том, чтобы сделать его ориентированным на пользователя по сравнению с датой-центрированием ... но я не знаю, хотите ли вы, чтобы я во все это углублялся)

Вы сделали очень хорошее наблюдение. Таблица активности будет быстро расти и увеличиваться. В прошлом я делал архивирование старых данных (скажем, старше 14 дней) в таблице ActivityHistory . В результате таблица активности будет иметь управляемый размер, и, если вам нужно провести исследование, вы всегда можете оглянуться на таблицу ActivityHistory .