1:1관계 테이블 설계, JPA사용시 바람직한 DB설계 방향 도움 부탁드려요. (feat.신입개발자)

Question

안녕하세요. 글 눌러주셔서 감사합니다.며칠째 고민해봐도 혼란한 DB설계 고민 중 글 올려봅니다. _ _ )테이블의 1:1관계에 대해서 JPA의 &#64;OneToOne을 키워드로 검색하다가현재 상황에 , 어떻게 해야 알맞는 설계일지 가늠이 안되어 우선 위 제목과 같은 질문을 드립니다.(갈수록 제가 객체지향에 맞지 않게 설계하고 생각하는건 아닌가 무한 의심도 되구요 ..ㅜㅜ)[ 프론트측 요구사항 ]회원 정보 상세페이지- 회원 정보 &#43; 회원의 고유한 스케줄이 함께 list로 보여집니다.회원당 1개 스케줄이 1:1로 할당이 되는 형태.(ex: 헬스 회원 1인 1개 락커)(&#43;&#43;추가 설명)member 1은 schedule 1이랑, member2는 schedule 2랑 매핑됩니다.member 한명당 schedule 하나만 갖습니다.(member당 schedule이 더 쌓이는 구조가 아니예요! member 생성 최초시, schedule도 한번만 생성됩니다.아래는 예시라서 그렇습니다. 제가 헷갈리게 적었네요. ㅜㅜ )(간략하게 예시 그림입니다.)회원 테이블과 스케줄내역테이블을 &#64;OneToOne으로 매핑하며 진행한다. (단방향 매핑 사례..? )1-1 추후, 스케줄내역테이블 쪽에서도 MemberId를 요구할 수도 있어서 양방향 매핑이 필요할 수 있음.스케줄 내역 테이블의 시퀀스는 값 자동이아닌, 회원 테이블의 시퀀스를 pk로 한다.Controller단계에서 각 MemberService와 SchedulingService를 이용,회원이 추가될 때, 스케줄도 수기 기입되는 형태로 처리한다.크게는 이 두가지 흐름 중에서 고민중입니다.chatGPT와 구글링을 통해 알아봤을 때는 ..객체지향의 성격과 JPA를 이용한다면 &#64;OneToOne을 이용하길 권하는데,위에 쓰인 이유와 마찬가지로 애매하게 글로만 이해한 사례로 적용하려다보니뭐가뭔지 점점 더 모르겠더라구요.다른 사례로, 사원의 연차 같은 거 생성할 때는 아무래도 초기 데이터가 정해져 있으니까사원 등록시, 연차개수 초기 데이터도 같이 수기 기입이 되도록 처리했었는데 말이죠...혹시 이런 1:1의 경우 어떻게 풀어가시는지 조언 부탁 드립니다.이런 DB 설계를 도움 받을 java backend 사수분이 안계신 상황에서어떻게 공부하면 좋을까요 ㅜㅜ...오늘도 긴 글 읽어주셔서 감사합니다.

장독깨기 · Accepted Answer

우선, 예를 든 헬스 회원 1인 1개 락커는 1:1 관계가 아닙니다.특정 회원이 영원히 그 락커를 점유하고 있는 것이 아니겠죠.두번째, 스케쥴 관련해서는요, 회원이 하나의 스케쥴만 가지고 있다면,2번 예시로 하면 됩니다. 그럼, 1:1 관계가 됩니다.1:1 관계는 이렇게 생각하면 편합니다.테이블을 분리하지 않을 경우 회원 테이블에 넣어도 무방할 경우 입니다.그니까, PK 가 같아야 1:1 관계가 성립이 됩니다.생각을 좀 해보셔야 할 것이 회원에게 최초로 스케쥴을 할당 합니다.그리고, 이 스케쥴을 수정하거나 추가해야 할 필요가 생깁니다.이때, 이 스케쥴의 변경 내역에 대한 관리가 필요 없이무조건 업데이트만 하더라도 무방하다면 1:1 관계로 하면 됩니다. (2번 예시)근데, 이런 경우는 업무적으로 잘 없는 것이 일반적 입니다.변경에 대한 관리가 필요하다면 1:n 관계가 될 것이고,&#34;1번 예시의 추후 필요할 수도 있음&#34; 에서 회원테이블의 shedule_id 를 삭제하고 처리하면 될 것입니다.마지막으로, JPA 사용 시 바람직한 DB 설계라는 건 없습니다.JPA 가 유행하고 이상하게 이런 생각하는 분들이 많은데요, 이 생각부터 얼른 버리셔야 합니다.JPA 는 그냥 DB 인아웃을 하는 하나의 수단일 뿐 입니다.DB 설계는 오로지 업무 관점에서만 보면 됩니다.그리고, DB 설계를 할 때는 항상 먼저 ERD 를 작성하고,전체 ERD를 보면서 시스템이 제공할 전체 기능에 대해 검토를 해보셔야 합니다.무작정 코드 부터 작성 할 일이 아닙니다. ㅎERD 편집 툴은 https://www.erdspace.com 여기 한 번 이용해보세요. :)아, 그리고, 저 툴에서 보면 DDL 뿐만 아니라 JPA 엔티티 소스를 생성 해주는 기능도 제공합니다. ㅎ

감독님테스트가하고싶어요 · Answer

1번으로 하시고요OneToOne 쓰지말고 OneToMany로 연결하세요.OneToOne은 단방향일 경우 상관이 없지만 양방향일 경우 N&#43;1 문제가 발생합니다.추후 양방향으로 변경될 가능성이 있다고하니 OneToMany를 쓰는게 좋겠네요.관련된 내용은 구글링해보면 나옵니다.

k3po · Answer

회원당 고유한 스케줄 내역이 있다 -> 스케줄 내역에 하나의 스케줄 만 있다 (x)회원당 고유한 스케줄 내역이 있다 -> 각 고유한 스케줄 내역에는 여러 개의 스케줄이 있다 (o)회원당 세부 스케줄이 하나만 있다는 건 말이 안 되므로 '스케줄 내역'과 그 안의 '세부 스케줄'을 개념적으로 구분하셔야 할 듯 합니다.따라서 @OneToOne 이 아닌 @OneToMany 로 하시는 게 맞지 않을까 합니다.

마도사 · Answer

ㅎ정말 간만에 글쓰네요...그동안 게으름증이 생겨서.....ㅋDB설계를 고민하면서...JPA관점을 고민하시네요...즉 두마리 토끼를 잡겠다는 심정으로....제가 보기엔 아직 그럴때는 안된것으로 보이는데요...죄송...ㅠ최근엔 JPA지만...고리짝 시절엔 뭐였지??? 넘 오래되서 기억이 잘안나지만....J2EE...EJB... 그때랑 지금이 반복인듯....ㅋ암튼....위글중에....@장독깨기님의 "DB 설계는 오로지 업무 관점에서만 보면 됩니다."가 정답입니다.명심하시고요.일단 1:1 인데 굳이 테이블을 분리한다??? 이거부터가 이상하네요. 물론 필드자체가 많아서 일부러 한다면 모르겠지만그럴 이유가 없어보입니다. 테이블 갯수가 많으면 좋은게 아니거든요. 즉 역정규화시 다시 붙여야할 테이블입니다.그냥 그렇다고요...질문자의 의도와는 다르게 DB 설계상의 관점에서는 그렇다는 겁니다.오늘도 무사히...^^

1:1관계 테이블 설계, JPA사용시 바람직한 DB설계 방향 도움 부탁드려요. (feat.신입개발자)

4개의 답변

기술 목록