ユーザーイベントデータを保存するための適切なテクニック

データベース設計に関しては、ほとんど独学です。私はこの共通の構造に落ち着いているので、この質問を提起していますが、それが最も効率的または「業界標準」の方法であるかどうか疑問に思っています。

私が設計するほとんどのデータベースにはユーザーテーブルがあり、その後、個人の活動は別のテーブルで追跡されます。データベースの美しさはこの種の効率を備えていることを理解していますが、アクティビティテーブルは、定期的に使用するすべてのユーザーから多くのイベントをかなり迅速に収集するため、中程度のユーザー使用量で非常に迅速に巨大なテーブルになります。このように成長させるのはこのベストプラクティスですか？または、テーブルの階層、日付に基づいて、またはユーザーの量ごとに、または他の何かに基づいて異なるテーブルに分割しますか？

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

学習を支援するために、何を改善できるかを知りたいだけです。

または、テーブルの階層、日付に基づいて、またはユーザーの量ごとに、または他の何かに基づいて異なるテーブルに分割しますか？

データベースの「パーティション化」の概念を調べてください。ほとんどのRDBMSはそれらをサポートしています（例：mysql、oracle、sql server、postgresql）。基本的に、RDBMSは、毎月/年/何でも別のテーブルに保存されるという事実を作成/管理するプロセスを処理し、それにアクセスするコードはそれを1つの大きなテーブルとして扱います。

ユーザー名、日付、またはデータにアクセスするために最も頻繁に使用されるものでパーティションを作成できます。（ユーザー中心にすることと日付中心にすることの利点/欠点があります...しかし、あなたが私にそれをすべて望んでいるかどうかはわかりません）

あなたは非常に良い観察をしました。アクティビティテーブルは、高速かつ大規模に成長します。過去に行ったことは、古いデータ（14日より古いなど）をActivityHistoryテーブルにアーカイブすることです。そうすることで続ける活動扱いやすいサイズにテーブルを、あなたが研究を行うために必要がある場合は、必ずで振り返ることができますActivityHistoryテーブル。