일단 마이바티스에 SQL 문과 같은 XML 묶음을 생성하여 작업하던 개발자들은 수많은 isEmpty 문 과 함께하는 select 쿼리 및 crud를 작성한다. 부등호 비교식이라도 들어가면 <![CDATA]>를 넣어주며 귀찮은 짓을 했었지. DBA가 있다면 테이블 조차 만들때 눈치를 봐야하던 시절. 사실 이게 아무리 최근 프로젝트라도 생산성 면에 있어서 대한민국 표준이었던건지 유지보수에서는 아직도 이걸 쓸것이다.
하지만 이제는 개발자 지향적인 ORM (Object-Relation Mapping) 의 기술 표준인 JPA를 이용하여 ORM 프레임 워크 중 하나인 hibernate를 사용할 수 있다(hibernate != JPA 라는 뜻)
그리고 스프링부트 프로젝트를 얼떨결에 나혼자 할 수 있는 기회(?)를 얻어 자유롭게 타임테이블 조정해 가면서 테스트 할 수 있게 되었다. 규모가 크지않아서 오히려 다행이라고 생각하였다
스프링부트+JPA조합이 처음이다
- DB: MariaDB
- FE Template : Thymleaf
- Server Framework : Springboot
DB가 사전에 짜여져있기 때문에 그것에 맞추기 위한 엔티티 구성과 구조의 매핑이 중요하다. 매핑 구조에 맞지 않는 데이터가 존재할경우 실행 조차도 할 수 없다. 예를 들면 다른 곳에서 참조값으로 사용하는 값일 경우 해당 기본키가 참조시 존재하지 않으면 에러를 뱉어 낸다 우선 데이터를 참조 관계 상관 없이 집어 넣고 보는 SI에서 사용하지 않을 만도 했다. 실제로 명목상 fk일뿐인 프로젝트가 n년간 한둘이 아니었음. JPA책을 보며 내적 친분만 있는 영한이 형은 국내에 제대로 된 서적이 없어서 이래 되었다 하셨다. 그 말도 맞지만 이건 SI만 주구장창 했던 내게 관계형 데이터베이스를 말로만 접하며 DBA의 무능을 부르짖으며 한탄했던 내게 JPA란 충격적이었다.
이번프로젝트는 워낙 단순한 조인과 조건문을 사용할 것이기 때문에 querydsl을 적용하지는 않았다
이 프로젝트에서 가장 독특한 점은 테이블의 구조가 관계 테이블을 사용하는데 그 와중 복합키가 필요하다. 해당 복합키로 유니크를 관리하기도 하며 고정적으로 들어가는 값이 키값에 속하기도 했다. 그리고 왜 존재하는지 알수가 없는 onetoone 테이블이 있는데 이건 너무 극단적으로 정규화 된 느낌이라 이질감이 너무 느껴졌다
일단 유저 테이블에서도 시퀀스를 사용하지 않는것도 충격적이었다 (!) 그래도 이것을 이용해서 로그 테이블도 사용하고 그런다. 난 그냥 하라는 대로 했을 뿐. 이것은 내 책임이 아님
조회, 입력, 수정에 거이 전부 엔티티가 연결되어있어 순환참조가 필요하며 양방향으로 모두 설계되었다. (로그 테이블만 빼고)
이렇게 설계된 것에 사실 의문이 없지않다. 물론 양방향이 필수로 구현되어 있어야 할 필요성이 많았다고 보았다. 그렇지만 혼자 하다보니 이 프로젝트의 성능에 관해 의문이 생겨가면서 규모가 작지만 남은기간안에 관계설정은 정말 열심히 최선을 다했으므로 정리를 하면서 남은 프로젝트 기간을 정리하면서 나중에도 도움이 될만한 설계들을 공유할 것이다.
