커스텀 필드 확장 전략 선택

상태

승인

후보군

방안	설명
A. 단일 테이블 + nullable 컬럼	stocks 테이블에 자체 필드를 nullable 컬럼으로 추가 + metadata JSON 컬럼으로 비정형 확장
B. 별도 extension 테이블	stock_extensions 테이블을 분리하여 확장 필드 관리
C. 전용 key-value 테이블	stock_attributes(symbol, key, value) 형태로 완전 동적 확장

결정

방안 A — 단일 stocks 테이블 + nullable 컬럼 방식

• 토스 API 제공 필드: symbol, name, english_name, market, currency — NOT NULL
• 자체 확장 필드: sector, description, is_active — nullable (추후 채움)
• metadata JSON 컬럼 추가: 정형화되지 않은 확장 필드 수용 (타입화는 추후)

결정 이유

• 단일 테이블로 조회 시 JOIN 없이 바로 접근 가능
• metadata JSON 컬럼으로 향후 비정형 필드 수용 여지 확보
• 현 규모(개인 투자 도구)에서 extension 테이블의 복잡도 불필요

검토 대안

방안	기각 이유
B. 별도 extension 테이블	JOIN 비용 발생, 관리 복잡도 증가. 현 규모 대비 과도한 설계
C. key-value 테이블	타입 안전성 없음, 쿼리 복잡도 급증, 인덱스 활용 어려움

트레이드 오프

• 득: 단순한 스키마, JOIN 없는 조회, metadata JSON으로 유연한 확장
• 실: 확장 필드가 많아질수록 테이블 컬럼 수 증가, metadata 내부 구조 타입 미보장