개요
EAV는 Entity-Attribute-Value의 약자이며, 기존 정규화 스키마에서 컬럼으로 고정하던 속성을 행 단위로 분리해 저장하는 데이터 모델 속성 집합이 사용자마다 다르거나 런타임에 추가되는 등 스키마를 선제 정의하기 어려운 경우 사용 속성이 희소할 때 저장 공간 절약과 스키마 변경 부담 감소에 유리
구조
일반적으로 세 컬럼 기반 테이블로 구성
- entity 데이터의 주체 예 사용자, 제품
- attribute 엔터티의 속성 예 이름, 색상
- value 속성의 실제 값 예 김철수, 빨간색
예시
엔터티가 사용자이고 속성이 이름, 나이, 이메일이라고 가정 일반 테이블 예 Users(UserId, Name, Age, Email) EAV 표현 예
- (userId=1, attribute=이름, value=김철수)
- (userId=1, attribute=나이, value=30)
- (userId=1, attribute=이메일, value=c@e.com)
장점
- 동적 속성 대응 스키마 변경 없이 속성 추가 가능
- 공간 효율성 실제로 채워지는 속성이 적은 희소 데이터에서 저장 효율 상승
단점
- 쿼리 복잡성 동일 엔터티의 여러 속성 결합 시 self join 또는 피벗이 증가하여 성능 저하 가능
- 데이터 타입 관리 어려움 value에 단일 컬럼을 쓰면 정적 타입 강제가 어렵고 애플리케이션 레벨 검증 부담 증가
- 데이터 무결성 관리 난이도 속성명과 허용값 관리가 분산되면 일관성 깨질 수 있음
적용 시 유의
- 속성 사전 관리 Attribute 테이블로 속성 키, 타입, 제약, 기본값, 허용값을 정의해 참조 무결성 확보
- 타입 처리 전략 value 타입을 문자열 하나로 두는 대신 타입별 컬럼 분리 또는 타입 컬럼 병행 도입 고려
- 인덱스 설계 (entity, attribute) 복합 인덱스 기본 자주 조회되는 속성에 선택적 커버링 인덱스 고려
- 읽기 최적화 보완 빈번한 리포팅 및 집계는 별도 마트나 머티리얼라이즈드 뷰로 분리
- 스키마 대체 금지 핵심 도메인까지 EAV로 일반화하지 말고, 예측 불가 메타데이터 구간에 한정해 사용
정리
EAV는 동적으로 변하는 희소 속성을 다루는 데 특화된 스키마 패턴 대신 쿼리 복잡도, 타입 강제, 무결성 관리 비용이 커지므로 메타데이터 영역에 제한적으로 적용하고, 속성 사전과 인덱스 전략으로 운영 리스크를 낮추는 것이 현실적 선택