• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

복합키, 대리키 질문

20.04.03 11:52 작성 조회수 533

0

DB 초보, JPA초보라 영한님 강의가 정말 큰 도움이 되고 있습니다.

아래와 같은 DB 구조인데

// 한시간단위 통계
device_data_hourly
	system_id   varchar	PK
	device_id   varchar	PK
	target_date datetime
        yyyymm      varchar	PK
	dd          varchar	PK
	hh          varchar	PK
	data        float

복합키를 생성하기 위해 영한님 JPA 책에서 @IdClass나 @EmbeddedId를 보고 있습니다.

1) 강의에서도 대리키를 강조하셨고, 
인터넷 검색해보니 예전에는 복합키를 매우 많이 썼지만, 요즘은 대리키를 많이 쓰는 추세인 것 같습니다.

위와 같은 경우는 
저렇게 복합키를 생성하면 index도 걸리니까, 별도로 index를 걸 필요도 없어서 괜찮아 보이는데,
JPA 구현상으로는 불필요하게 code가 복잡해지는 것 같습니다.

그냥 대리키를 사용하고 index(system_id, device_id, yyyymm, dd, hh)를 걸어주는게 더 나을까요?

2) 테이블에서 yyyymm, dd, hh, mm 등의 필드를 별도로 분리해서 두는 이유가
   Batch Task 등에서 통계 조회시 group by 등을 할 때 성능 최적화를 위해서 저렇게 하는 것인가요?
   yyyymm, dd 등의 필드가 아니라 target_date(datetime)을 기반으로 값을 추출해서 조회하면 성능이 많이 차이나나요?

3) 위 통계 Table의 target_date 필드의 필요성
   yyyymm, dd, hh, mm 등의 필드가 있는데도 target_date를 별도로 두는 이유는  검색시 날짜 시간 구간 검색 query시 편의를 위해서인가요?

질문을 쓰고 보니, JPA 질문이 아니라 그냥 Database 질문이 되버렸네요. ^^;;

답변 3

·

답변을 작성해보세요.

0

네 이부분은 정말 case by case인데요^^

꼭 필요하면 이 부분은 역정규화를 하면 됩니다^^!

감사합니다.

0

GPK님의 프로필

GPK

질문자

2020.04.08

답변 감사드립니다.

해당 대리키PK를 다른 테이블에서 외래키로 참조할 때, 
검색시에는 주로 natural key 값 같은 것이 들어오니 대리키값을 바로 검색에 사용할 수가 없고,
2개 테이블을 join해서 검색해야할텐데, (PK가 natural key 라면 join 없이 바로 검색 될테니...)

이런 join에 대한 부담 같은 것은 현업에서는 크게 부담 안되는 수준인가요?
case by case일 수도 있겠습니다만..^^;;

0

안녕하세요. GPK님^^

1) 네 대리키를 사용하고 unique index를 추가로 걸어주시는 것을 저는 권장합니다.

2) 저는 이렇게 필드를 나누는 부분에 크게 동의하지 않습니다. 물론 데이터베이스 상황에 따라서 더 최적화가 물론 될 수 는 있지만, datetime으로 잡아도 충분히 인덱스가 잘 운용될 수 있습니다.

3) 조회 쿼리를 편리하게 만들려고 이렇게 나누어 둔 것 같습니다.

과거에 이런 방식으로 문자를 가지고 해결하는게 많았는데요. 최근에는 가급적 date, datetime 등등 날짜는 날짜 타입으로도 충분히 문제를 해결할 수 있습니다. 저는 날짜는 날짜로 해결하는게 더 나은 방법이라 생각합니다.