⚡ 생각대로 살지 않으면 사는대로 생각한다.
⚡ 나는 어차피 잘 될 놈이다. 이미 잘 되고 있고, 계속해서 잘 되고 있다.
데이터베이스 스키마 자동 생성
- DDL을 애플리케이션 실행 시점에 자동 생성
- 테이블 중심 -> 객체 중심
- 일일이 테이블을 다 만들어놓고, 개발을 했지만 JPA는 그럴 필요가 없다.
- 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
- 이렇게 생성된 DDL은 개발 때만 사용
- 생성된 DDL은 운영서버에서는 사용하지 않거나 적절히 다듬은 후 사용!
옵션 | 설명 |
---|
create | 기존테이블 삭제 후 다시 생성(DROP+CREATE) ※ drop을 하고, create를 한다. |
create-drop | create와 같으나 종료시점에 테이블 DROP |
update | 변경분만 반영(운영 DB에는 사용하면 안 됨) 단 지우는 건 안 됨! |
validate | 엔티티와 테이블이 정상 매핑되었는지만 확인 |
none | 사용하지 않음 |
데이터베이스 스키마 자동 생성 - 주의
- 운영 장비에는 절대
create
, create-drop
, update
사용하면 안 된다.
- 개발 초기 단계는
create
또는 update
- 테스트 서버는
update
또는 validate
- 스테이징과 운영 서버는
validate
또는 none
영한좌: "개발하면 할수록 많이 느끼는 게, 어.. 사실 뭐 테스트 서버 그니까 개발 서버.도 가급적이면 쓰지마세요 이제.. 운영서버 특히 그냥 쓰지마시고요"
- 현업에서 데이터가 수천만 건 있는 상태에서 Alter를 잘 못 치면, 시스템이 중단될 수도 있다. 그래서 애플리케이션 로딩시점에 시스템이 자동으로 Alter같은 걸 쳐주는 것은 굉장히 위험하다.
Alter 테이블을 테스트서버나 개발서버에 직접 반영해서 잘 동작하는지 확인하고, DBA한테 검수를 받고, 적용하는 걸 권장함.
운영장비에는 사용하면 안 된다.
DDL 생성 기능
- 제약 조건 추가: 회원 이름은 필수, 10자 초과X
- @Column(nullable = false, length = 10)
- 유니크 제약조건 추가
- @Table(uniqueConstraints = {@UniqueConstraint(name = "NAME_AGE_UNIQUE", columnNames = {"NAME", "AGE"} )})
- 제약 조건들은 애플리케이션 실행에는 영향을 주진 않고, 데이터베이스 DDL 생성에 영향을 준다. JPA의 실행 매커니즘에 영향을 주는 것은 아니다.
- DDL 생성 기능은 DDL을 자동 생성할 때만 사용되고 JPA의 실행 로직에는 영향을 주지 않는다.
-끝-