요즘 Jpa 안 쓰는 곳이 없을 것 같다. Jpa를 사용하면서 ddl-auto 설정을 update로 사용하는 곳이 있는지 잘 모르겠는데..
( 난 비추.. update 옵션은 데이터 손실 위험도 있고 DDL 변경이 자동으로 일어나며 원치 않은 마이그레이션이 발생할 수 있게 때문에 지양하는 편이다. )
학습을 위한거라면 상관없겠지만 현장 필드에서 프로젝트를 진행할 땐 validate로 설정하는 게 좋다.
( 팀플이든 솔플이든,, )
DDL은 SchemaCreator 구현체를 이용하면 Entity를 통해 쉽게 만들 수 있다.
( 놀라운건 이 방법을 09년도부터 배워서 사용해왔다능..;; 습관의 중요성! )
또 Jpa로는 쿼리문 생성의 한계가 있기 때문에 DDL 생성 후 추가적인 쿼리를 작성해도 된다.
( fulltext index 등.. )
로컬에서는 이런식으로 쿼리문을 생성해서 개발을 진행하고 ( loc, dev, prod 폴더로 sql파일을 관리하는 편 ), dev와 prod는 flyway를 통해 반영하면 히스토리 관리도 되니까 추적하기도 쉽고, 다른 팀원이 작성한 쿼리문을 보고 분석하고 파악하는데 도움이 되기도 한다.
( 충격이였던건 팀 프로젝트를 진행하는데 local DB를 사용 안 하고 개발 DB에 직접 붙어서 작업하는 개발자가 있더라..
validate 검증 단계에서 계속 에러 나는데 설명을 해줘도 끝까지 개발 DB에 붙어서 하더라는.. docker-compose.yml 파일까지 제공을 해줬건만... )
개발일을 하면서 쿼리를 직접적으로 다루면 신경써야할 부분이 많아서 ( Table <=> Domain 간의 매핑 문제 ) Jpa를 안 쓸 수가 없더라.
물론 Jpa로 구현할 수 없는 쿼리도 존재해서 ibatis를 아직까지 사용하는 곳이 많을 것 같긴 한데, 될 수 있으면 직접 쿼리를 작성하는 건 피하고 싶다.
굳이 쿼리를 직접 짜야하는 상황이 온다면 Jooq 같은 걸 도입해 보는 걸 추천한다.
Jpa는 Entity를 기반으로 동작한다면, Jooq는 테이블 스키마 기반으로 동작하는 프레임워크다.
Jpa를 쓰면서 사용할 수 없었던 쿼리문을 Jooq를 통해 사용할 수 있다. ( union 같은 것들.. )
또한 Jooq는 테이블 기반으로 안전한 DSL 쿼리를 작성할 수 있어, 복잡한 쿼리를 컴파일 타임에 검증할 수 있다.
단점도 있긴 하다. 오픈소스 DB에서만 무료로 사용할 수 있다. 즉 oracle이나 mssql 사용 시엔 돈을 지불해야 한다.
그것 말곤 단점은 잘 모르겠다. 어차피 복잡한 쿼리는 코드로 만들어도 복잡할 수밖에 없으니 이걸 단점이라 말하기엔.. /_-;;
아무튼 개발을 하면서 최대한 리스크를 줄이고 싶은 욕심이 있는데.. 요즘 블로그들을 찾아보면서 더 나은 방법이 있을까 공부하는 와중에 최근 프로젝트에서 있었던 경험을 끄적여보았다....;;
여담으로. 프로젝트 마무리 되어갈 때쯤 테이블 명세서를 만들어야 하는 일이 생겼다. 어느 프로젝트를 진행하든 당연히 만들어야 하는 문서중 하나였는데 밑에 개발자 시키려다가 너도 나도 시간낭비 하는게 싫어서 Jpa를 통해 테이블 명세서를 만들어봤다.
Jpa가 아니더라도 Metadata를 통해 만들 수 있지만 다른 DB마다 구현을 해야 하는 게 귀찮고 이런 일에 힘 빼고 싶지 않아서 그냥 Jpa를 사용해서 만들어뒀다.
Jpa를 잘 활용하면 도메인에서부터 데이터베이스, 그리고 문서까지의 흐름을 하나의 모델로 통합해 일관성 있게 유지할 수 있다.