본 포스팅은 인프러의 JPA 기본편을 수강하고 정리하는 내용입니다.
데이터베이스 스키마 자동 생성
- DDL을 애플리케이션 실행 시점에 자동 생성
- 테이블 중심 -> 객체 중심
- 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
- Oracle은 varchar2, MySQL은 varchar
- 이렇게 생성된 DDL은 개발 장비에서만 사용
- 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용
데이터베이스 스키마 자동 생성 - 옵션
hibernate.hbm2ddl.auto
create-drop옵션은 테스트케이스를 실행 후 마지막에 깔끔하게 날리고 싶을 때 사용한다.none은 주석으로 해도되고 실제 특별한 것을 지정하진 않는다.
데이터베이스 스키마 자동 생성 - 실습
- 스키마 자동 생성하기 설정
- 스키마 자동생성하기 실행, 옵션별 확인
- 데이터베이스 방언 별로 달라지는 것 확인(varchar)
데이터베이스 스키마 자동 생성 - 주의
- 운영 장비에는 절대 create, create-drop, update 사용하면 안된다.
- 개발 초기 단계는 create 또는 update
- 개발 서버 또는 테스트 서버는 update 또는 validate
- 스테이징과 운영 서버는 validate 또는 none
Note: 테스트 서버나 개발 서버도 가급적 안쓰는게 좋다. 운영 서버는 절대 쓰면 안된다. 개발 서버나 스테이징 서버의 validate 정도까진 괜찮다. 데이터가 몇 천만건 있는 운영 서버에서 alter를 잘 못치면 시스템이 중단될 수 있다. 잘 알고 치면 괜찮다. 애플리케이션 로딩 시점에 시스템이 자동으로 alter를 쳐주는게 굉장히 위험하다.(5분 정도 시스템이 멈춰도 대장애가 나는 것이므로) alter 스크립트를 직접 만든 걸 테스트 서버에 잘 동작하는지 반영해보고, 문제 없으면 운영 서버에 반영해보는 것을 권장한다.
결론은 로컬PC에서만 자유롭게 하고, 여러 명이 쓰는 개발 서버나 스테이징, 운영 서버에는 가급적이면 안 쓰는걸 권장한다. 운영 서버에 반영할 때 스크립트를 다듬어서 반영하는걸 추천한다.
create의 경우엔 drop하고 생성한다. 그래서 운영 테이블이 몇 개가 날라간 경우도 있다. update도 잘못된 경우 alter 문이 실행되어 DB테이블에 락(Lock)이 걸리게 된다. 그래서 몇 분동안 서비스가 중단 될 수도 있다.
제일 중요한건 웹 애플리케이션 계정은 alter나 drop을 못하도록 근본적으로 계정 자체를 분리하는게 맞다.
DDL 생성 기능
- 제약조건 추가: 회원 이름은 필수, 10자 초과X
@Column(nullable = false, length = 10)
- 유니크 제약조건 추가
@Table(uniqueConstraints = {@UniqueConstraint( name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})
- DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의
실행 로직에는 영향을 주지 않는다.