집계 결과를 미리 저장하는 두 방법

같은 목표를 가지지만, 차이는 누가 갱신과 조회를 책임지느냐에 있습니다.

예를 들어 orders를 TRUNC(order_date) 기준으로 일별 집계해 저장할 때, Materialized View는 DBMS 기능을 활용하고 요약 테이블은 애플리케이션이나 배치가 직접 운영합니다.

공통 출발점

둘 다 조회를 빠르게 하려고 미리 계산된 결과를 저장합니다. 학습 포인트는 “저장한다”보다 그 다음 단계인 갱신 방식, 정합성 책임, 엔진 의존성이 어떻게 달라지는가입니다.

비교 축

DBMS 기능

Materialized View

리프레시와 쿼리 재작성 같은 기능을 엔진이 맡습니다.

직접 설계

집계 테이블과 적재 로직을 직접 만들고 직접 호출합니다.

운영 책임 누가 갱신을 관리하는가

DBMS가 리프레시 관리

자동 리프레시 옵션으로 운영 부담을 줄일 수 있습니다.

배치·트리거·수동 SQL을 직접 운영

갱신 시점과 적재 로직을 애플리케이션이 명시적으로 설계합니다.

조회 경로 기존 쿼리가 어떻게 연결되는가

Query Rewrite로 투명하게 활용 가능

원본 테이블을 조회해도 엔진이 MV로 우회할 수 있습니다.

요약 테이블을 직접 참조해야 함

어떤 화면과 리포트가 이 테이블을 쓸지 쿼리 수준에서 분명히 관리합니다.

정합성과 제어 일관성, 디버깅, 유연성

정합성은 리프레시 정책에 좌우

정의는 SQL로 간결하지만 내부 동작과 디버깅은 DBMS 특성에 더 의존합니다.

구현 품질이 곧 정합성 수준

자유롭게 설계하고 직접 검증할 수 있지만, 그만큼 실수도 직접 책임져야 합니다.

적합한 환경 엔진 지원과 이식성

Oracle, PostgreSQL 같은 지원 엔진에서 유리

DBMS 기능을 활용해 집계 조회를 더 투명하게 운영할 수 있습니다.

모든 DBMS에서 가능, MySQL에서는 사실상 기본 선택

MV가 없는 환경에서도 같은 목적을 구현할 수 있는 가장 현실적인 방법입니다.

언제 MV인가 지원 DBMS 위에서 운영 자동화와 쿼리 투명성이 더 중요할 때

집계 자체보다 “엔진이 알아서 맞춰 주는 운영성”을 사고 싶다면 MV가 더 잘 맞습니다.

언제 요약 테이블인가 이식성, 직접 제어, MySQL 대응이 더 중요할 때

운영 로직을 직접 가지더라도 어디서나 같은 패턴으로 구현해야 한다면 요약 테이블이 단순합니다.