사용자 이벤트 데이터를 저장하기위한 적절한 기술

나는 데이터베이스 디자인에 관해서는 대부분 독학입니다. 나는이 공통 구조에 정착했기 때문에이 질문을 제기하고 있지만 그것이 가장 효율적인지 또는 '산업 표준'방법인지 궁금합니다.

내가 디자인 한 대부분의 데이터베이스에는 사용자 테이블이 있고 다른 테이블에서 개인 활동이 추적됩니다. 데이터베이스의 아름다움은 이러한 종류의 효율성을 갖는 것임을 이해하지만 활동 테이블은 정기적으로 사용하는 모든 사용자로부터 많은 이벤트를 상당히 빠르게 수집하므로 적절한 사용자 사용으로 상당히 빠른 테이블이됩니다. 이 방법으로 성장시키는 것이 가장 좋은 방법입니까? 아니면 날짜, 사용자 수 또는 기타 항목을 기준으로 테이블 계층 또는 다른 테이블로 분할됩니까?

+--------------------+                   +------------------------+
|   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는 매월 / 연도 / 무엇이 별도의 테이블에 저장되어 있다는 사실을 작성 / 관리하는 프로세스를 처리하도록하고 액세스하는 코드는이를 하나의 큰 테이블로 취급합니다.

사용자 이름, 날짜 또는 가장 자주 데이터에 액세스하는 데 사용되는 것으로 파티션을 나눌 수 있습니다. (사용자 중심 대 날짜 중심으로 만드는 것의 장점 / 단점이 있습니다 ...하지만 모든 것을 원하는지 모르겠습니다)

당신은 아주 좋은 관찰을했습니다. 활동 표는 빠르고 커질 것입니다. 내가 과거에 한 일은 오래된 데이터 (예 : 14 일 이상)를 ActivityHistory 테이블에 아카이브하는 것 입니다. 이렇게하면 활동 테이블이 관리 가능한 크기로 유지되며 조사해야 할 경우 항상 활동 기록 테이블을 다시 볼 수 있습니다 .