Event History Model

이벤트 이력 모델은 행동의 정의와 실제로 일어난 행동의 로그를 분리해, 분석용 이력을 정규화하면서도 행동 맥락을 남기는 패턴이다.^[1]

기본 모델

원문은 사용자 마스터와 함께 위 정의 테이블·로그 테이블을 나누고, event log가 action log에 연결되는 구조를 제안한다.^[1:1]

맥락을 확장하는 순서

flowchart LR
    A[Action definition] --> AL[Action log]
    E[Event definition] --> EL[Event log]
    AL --> EL
    EL --> M[Key-value metadata]

1. 화면 전환 맥락은 event_logs에 from_screen·to_screen 컬럼을 추가해 기록하고, event log는 action_log_id로 action log에 연결한다.^[1:2]
2. 고정 열로 표현하기 어려운 view_stack, target_element_id 같은 값은 key-value 메타데이터로 확장한다.^[1:3]
3. event와 action의 연결을 유지해 "어떤 흐름에서 어떤 세부 동작이 일어났는가"를 분석할 수 있게 한다.^[1:4]

적용과 절충점

• 이 모델은 사용자 행동 패턴, 화면 전환 퍼널, event-action 인과관계 분석에 적합하다.^[1:5]
• 원문의 최종 하이브리드 모델은 정의/로그 분리 위에 타입 명시 컬럼(action_logs), Key-Value 확장(event_log_attributes), 인과관계 추적(trigger_action_log_id)을 더한 구성이며, 타입별 컬럼은 비정형 정보 저장에 부적합해 NULL 값이 늘어나므로 비정형 맥락을 key-value로 보낸다.^[1:6] 자주 조회하는 속성은 고정 열로 두고 변화가 잦거나 선택적인 속성만 key-value로 보내는 기준, 그리고 이것이 조회성과 확장성 사이의 균형이라는 평가는 이 page의 해석이다.
• key-value 영역을 무제한으로 넓히면 타입 검증과 질의가 어려워질 수 있다는 점은 이 패턴을 적용할 때 별도로 검토해야 할 설계상 추론이다.

관련

• Audit Log: 변경의 책임성과 추적을 위한 로그이며, 행동 분석 중심인 이 패턴과 목적이 다르다.
• Domain Model Design: action/event 정의를 의미 있는 도메인 개념으로 모델링하는 출발점이다.

출처