created_at, updated_at 자동화는 DB, JPA ... - 인프런

안녕하세요 영한님!

11강에서 created_at과 updated_at 값을 데이터베이스의 DEFAULT CURRENT_TIMESTAMP과 ON UPDATE CURRENT_TIMESTAMP 기능을 사용하는 가이드에 대해 다뤄주셨는데요.

Spring Data JPA를 사용하면 아래와 같이 @EnableJpaAuditing 을 사용하여 Application 단에서 Auditing 기능을 사용할 수 있는 걸로 알고 있습니다.

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
@Getter
public class BaseEntity {

    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;
}

만약 위와 같은 JPA 기능을 데이터베이스와 같이 사용한다면, Application 단에서 createdAt , updatedAt 값이 채워진 채로 저장되고, DB에서 한 번 더 덮어쓰는 구조가 될 것 같더라고요.

실무에서 created_at과 updated_at 값을 채울 때, @EnableJpaAuditing 과 데이터베이스의 DEFAULT CURRENT_TIMESTAMP과 ON UPDATE CURRENT_TIMESTAMP 중 어떤 것을 사용하는게 더 나은 선택일지 궁금합니다. 각각을 사용했을 때 유리한 케이스가 따로 있을까요?

안녕하세요, 인프런 AI 인턴입니다. bebe님!

created_at과 updated_at 값을 채울 때 JPA Auditing을 사용할지, DB의 DEFAULT CURRENT_TIMESTAMP와 ON UPDATE CURRENT_TIMESTAMP를 사용할지는 프로젝트의 특성에 따라 다를 수 있습니다.

JPA Auditing 사용 시 장점:
- 비즈니스 로직에 밀접: Application 단에서 모든 로직을 처리하기 때문에 데이터의 생성 및 수정 시점이 비즈니스 로직 흐름에 명확히 드러날 수 있습니다.
- 테스트 용이성: JPA Auditing을 사용하면 로컬 환경에서 쉽게 시간을 조작하거나 테스트할 수 있습니다.
DB DEFAULT CURRENT_TIMESTAMP와 ON UPDATE CURRENT_TIMESTAMP 사용 시 장점:
- 일관성 보장: DB에서 모든 변경을 처리하므로, 애플리케이션 코드의 버그나 실수에 의해 타임스탬프가 잘못 기록될 가능성이 줄어듭니다.
- 다양한 클라이언트 지원: DB 레벨에서 타임스탬프를 관리하면 여러 클라이언트(예: 다양한 서버 인스턴스, 외부 API 클라이언트) 간의 시간 동기화 문제를 줄일 수 있습니다.

실무에서의 선택:
- 규모가 큰 애플리케이션이나 멀티 서버 환경에서는, DB에서 타임스탬프를 관리하여 모든 서버 간의 일관성을 유지하는 것이 더 나을 때가 있습니다.
- 반면, 개발자들이 비즈니스 로직에 대한 통제권을 강화하고 싶거나, 테스트 환경이 중요하다면 JPA Auditing을 선택할 수 있습니다.

관련 질문들에서 더 풍부한 정보를 얻고 싶으시면 아래 링크를 참조하세요:

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변

created_at, updated_at 자동화는 DB, JPA 중 어느곳에서 하는게 좋을까요?