JPA DB 스키마 자동 생성 이상과 현실

객체 지향 애플리케이션은 테이블이 아닌 객체 구조에 집중해야 한다.

 

●  JPA는 엔티티 클래스 정의만으로 DDL을 애플리케이션 실행 시점에 자동으로 생성해준다.

 

●  DDL 생성 기능은 JPA의 실행 로직에는 영향을 주지 않는다.

 

●  데이터베이스 방언(Dialect)를 활용하여 데이터베이스에 맞는 적절한 DDL을 생성한다.

 

●  따라서 테이블 중심 설계 대신 객체 중심 설계를 할 수 있게 된다.

 

DDL 생성 전략 설정

hibernate.hbm2ddl.auto 속성

값	설명
create	애플리케이션 실행 시 테이블 삭제 후 생성(DROP + CREATE)
create-drop	create와 같지만, 애플리케이션 종료 시 테이블 제거
update	테이블이 없으면 생성하고, 변경 사항 반영
validate	엔티티와 테이블이 정상 매핑되었는지만 확인
none	사용 안함

application.yml 설정

spring:
  jpa:
    hibernate:
      ddl-auto: create

 

주의사항

 

●  운영 장비에는 create, create-drop, update를 절대로 사용하면 안된다.

 

●  create / create-drop은 데이터가 전부 날아가기 때문에 실무에서는 절대 사용하지 않는다.

 

●  테스트 서버에서 또한 create를 사용하면, 다른 개발자가 테스트 했던 데이터가 배포할 때마다 날라가 버린다.

 

●  update는 제약 조건, 컬럼 삭제 등 정확히 반영되지 않는 문제가 있어서 실무에서 사용하기에는 신뢰도가 낮다.

 

●  운영 환경에서 데이터가 몇 천 만건 있다고 할 때, alter가 나가는 순간 락이 걸리면서 시스템이 몇 분동안 중단될 수 있다.

 

●  운영 환경에서는 none 또는 validate를 사용하자.

사실 웹 애플리케이션에서 사용하는 DB 계정에는 alter, drop 권한을 주면 위험하다.

 

결론

●  사실 테이블 중심 설계에서 객체 중심 설계로 바뀐다는 것은 이상적인 방향이긴 하지만, 실무 기준으로 보면 현실과 다르다.

 

●  현실적으로 DB 구조는 여러 부서 간 협의로 확정되며, 객체 중심 설계는 개발자의 판단일 수 있어 조직 전체 기준이 되기 어렵다.

 

●  객체 모델은 바뀌기 쉽지만, DB 컬럼 이름 변경, FK 재설정, 스키마 변경은 대단히 위험하고 비용이 크다.

 

●  제일 중요한 문제는 JPA가 DDL을 100% 커버하지는 못한다.

 

●  따라서 대부분 사전 정의된 ERD에 맞추어 엔티티 클래스를 정의한다.