작성
·
355
답변 1
1
안녕하세요. pkt369님 좋은 질문입니다.
저는 실무에서 특별한 일이 없는한 Long + 대체키 + 키 생성전략을 사용합니다.
데이터가 너무 많아서 파티셔닝 해야 하거나, 특별히 UUID를 사용해야 하는 경우를 제외하면 대체키 방식을 사용합니다.
여기서 대체키라는 것은 오라클을 사용하면 시퀀스, MySQL을 사용하면 auto increment를 말합니다.
그리고 데이터베이스마다 대체키를 만들어주는 방법이 다른데요. 실무에서는 이 부분을 데이터베이스에 맞게 지정해야 합니다.(실제 적용할 때는 AUTO를 사용하면 안됩니다.)
오라클은 시퀀스 전략, MySQL은 IDENTITY를 사용하시면 됩니다.
감사합니다.
안녕하세요. 중국산북극곰님
말씀하신 방식을 사용해도 데이터를 저장할 때는 크게 문제가 없을 것 같아요.
그런데 em.find()와 같은 방식으로 JPA의 엔티티를 조회할 때는 @Id가 있는 대체키로만 조회하기 때문에 전체 파티션을 다 조회할 가능성이 있습니다.
이런 부분만 유의해서 사용한다면 크게 문제는 없을 것 같아요.
감사합니다.
안녕하세요.
저도 강의를 듣고 실무에 적용하다가 찾아보고있었는데요.
혹시 파티셔닝이 필요한 케이스에는 Long + 대체키 + 키 생성전략이 불가능한가요?
파티셔닝을 제외한 방식이라고 하신 이유가 궁금합니다.
아래와 같은 방식은 불가능할까요?
파티셔닝을 위해서 DB에는 대체키(자동증가값) + CreatedAt(생성일자를 파티션키로 사용한다는 가정)
2. JPA에서는 키 생성전략으로 Identity(MySql)로 지정하고 createdAt 필드는 ID지정을 안하고 @PrePersist로 영속상태 만들기전에 주입하는 방식
혹시 위 방법이 단점이 있거나 불가능할까요?