이력관리 질문

ㅎㅎ 뭔가 저도 기분이 좋네요.

네 JPA활용2를 들으면 복잡한 상황에서 데이터가 많을 때 어떤 식으로 최적화해서 JPA로 데이터베이스를 조회하고, API를 만들 수 있는지 노하우를 전해드립니다.

그런데 활용2를 듣기전에 JPA 기본편을 꼭 먼저 들어서 기본기를 탄탄히 다져야 온전히 이해할 수 있습니다.

안녕하세요. Choonghee Lee님^^

이력 테이블을 원본 테이블에 같이 관리하면 성능이 떨어집니다. 그런데 성능도 성능이지만, 목적이 다르기 때문에 이력은 가급적 다른 테이블로 관리하는 것이 유지보수하기에 더 좋습니다.

다른 테이블에서 주문 테이블을 조인하는 상황까지 고려해보시면 이력 테이블을 별도로 두는게 훨씬 더 좋습니다^^!

(물론 정말 단순한 테이블은 하나로 관리하기도 합니다.)

이력 테이블 관리는 여러가지 방법이 있는데, 저는 최초 insert부터 양쪽에 중복으로 같은 데이터를 보관하는 방법을 선호합니다. 이력테이블이 원본 테이블의 최신 데이터도 함께 보관하는 것이지요. 이렇게 해두면 이력 테이블만 조회해도 이력 내역을 다 조회할 수 있고, 개발도 일관성이 있어서 편리합니다.

도움이 되셨길 바래요.

안녕하세요. Choonghee Lee님

선분이력이 혹시 어떤 것을 말씀하시는지요?

단순히 주문의 상태가 변경된 이력 관리나, 상품의 상태가 바뀐 이력을 관리하는 것이라면 예를 들어드릴께요.

Order 엔티티와 OrderHistory 엔티티를 두고,

Order 엔티티가 변경될 때 마다 OrderHistory 엔티티를 만들어서 저장하면 됩니다. 이때 단순한 방법은 Order가 변경되는 서비스 로직에서 해당 로직을 함께 처리하면 됩니다. Order 엔티티가 OrderHistory를 몰라도 괜찮습니다. 이력 조회가 필요하면 OrderHIstory를 따로 조회하면 됩니다.

도움이 되셨길 바래요.

감사합니다! 로드맵에 써있는 야생형 순서로 들으려고 합니다.
종종 질문하겠습니다!

오! 감사합니다. 선배 개발자의 노하우를 들은 것 같아 기분이 좋네요.
JPA 활용 2를 들으면 다량의 데이터에 대한 성능 최적화도 같이 알 수 있게 되나요??

말씀해주신대로 주문 테이블과 주문 이력 테이블이 따로 있으면
데이터가 정말 많이 쌓여있는 경우에
주문 테이블 하나에서 이력을 관리하는 경우보다 속도가 더 떨어질까요?

제가 말하는 테이블 하나에서 이력을 관리하는 것은 아래의 그림과 같은 것 입니다.

하나의 컬럼만 변경되어도 새로운 로우가 생성되고 유효종료일로 최신 데이터인지 이력 데이터인지 구분하는 것이지요!

답변 감사드립니다!
강의가 재미있어서 계속 듣고 있습니다.