설계의 중요성
저는 불과 몇년전까지만 해도 설계가 무엇인지도 거의 모르는 상태이고, 중요한 부분도 아니라고 여겼었습니다.
하지만 대학 교과과정을 밟으면서 여러 프로젝트를 진행해보니 아무리 오래걸려도 설계가 완벽하게 되어있어야 개발을 수월하게 할 수 있고, 협업할 때도 소통이 원할하게 된다는 것을 깨달았습니다.
개발자의 직무는 단순히 코드만 작성하는 기계적인 직무가 아니라고 생각합니다. 어떤 프로그램을 만들지 기획이 정해지면 이를 어떤 방식으로 개발할지 생각하고, 더욱 효율적인 방법을 스스로 찾아내고, 이러한 코딩 외적인 부분들에 더욱 힘을 주는 것이 올바른 방향이라고 생각합니다.
각설하고 아래에서는 저희 팀의 DB 설계부터 작성하겠습니다.
ERD
현재 개발 예정인 부분이 너무 많지만 팀원이 적어 한정된 부분들에 대해서만 DB 설계를 진행하였습니다.
현재 예방접종 관련 내용은 조사가 부족하여 추가가 되어있지 않고, 마켓부분은 다른 개발에 비해 우선순위가 밀리기 때문에 별도의 테이블을 생성해두지 않았습니다.
https://www.erdcloud.com/d/64EKSxiqYZaRgFTAS
해당 링크로 가시면 생성(수정)된 공개 ERD를 확인하실 수 있습니다.
의문점
팀원들과 DB설계를 오랜 회의에 걸쳐 진행하고, 집으로 돌아와 ERD를 설계하는 도중 아래의 2가지 의문점이 들었습니다.
- Spring에서 외래키를 기본키로 가질 수 있는가? 가진다면 어떤 방식을 채택해야 하는가?
- 연관관계를 설정할 때 식별 관계인지 비식별 관계인지 명시하도록 하는데, 둘의 차이가 무엇인가?
두 의문점은 사실 같은 방향을 가리킵니다. 1:N의 연관관계를 설정하는 것은 보통 N의 엔티티에 1의 외래키를 가져오는 것인데, 이때 N이 독립적으로 존재하지 못해 외래키를 기본키로 참조해야한다면 식별관계, 독립적으로 존재가 가능하고 참조만 하는 경우라면 비식별관계로 정의합니다.
예를 들어 게시물과 게시물 사진이 있다고 했을 때, 게시물 사진은 게시물이 없다면 존재할 이유가 없는 엔티티이므로 둘은 식별 관계로 설정되어야 합니다.
다른 예시로 게시물과 회원은 별도로 존재할 수 있는 엔티티지만, 게시물의 작성자에서 회원 엔티티가 필요하므로 이는 비식별 관계로 설정되어야 합니다.
하지만
SpringBoot를 사용하여 엔티티를 생성할 때는 꼭 필요한 경우가 아니라면 비식별관계로 설정하고, 고유의 ID값을 지정해주는 방식을 추천합니다. 식별관계로 설정한다면 양쪽의 외래키를 애트리뷰트로 가지는 별도의 테이블을 또 만들어서 연관관계를 설정해 주어야하고, 자식 엔티티들까지 부모에게 영향을 받기 때문입니다.
이번 프로젝트에서는 사용자가 즐겨찾기한 게시판 데이터와 좋아요를 제외하고는 모두 비식별관계로 설정하였습니다.
