이력서 저장 테이블 구조 재구성

배경

일단 동작되게 만들어!!!

이게 문제였는지 현재는 너무 화면에 치중된 ERD가 나오고 화면이 바뀌면 Controller, Service, Repository, 심지어 Database까지 모두 변경이 이루어지게 된다 (천지개벽!)

또 화면에 ERD를 맞추다 보니 API를 찍어내는 것 이외의 작업이 없다

 

또한 추후 커스텀한 템플릿을 만들어 제공을 해주기 위한 Should 기능이 있는데 이러한 정적으로 구조화된 DB를 가지고서는 유연하게 많은 구조를 저장을 하기 불가능 하다고 생각이 되어 이를 하나의 테이블로 변경을 해보고자 한다

반응형

현재 화면 상태 및 ERD

모든 각 Block 들 마다 테이블로 분리되어 다대일 매핑이 이루어져 있다

 

구상중인 새로운 Entity

이를 해결할 방법으로는 다단계 Table!!

하나가 여러개를 계속해서 증식할 수 있고 최고 등급 컬럼이 모든것을 먹을 수 있도록

320x100

구상도 - New Entity - Component (Block단위)

{
        "content": "업무경험", // -> 이 부분은 Enum 으로 code화
        "details": [
                {
                        "type": "companyName",
                        "content": "그렙 Grepp",
                        "details": [
                                {
                                        "type": "date",
                                        "content": "2022.09 ~ 2023.12",
                                        "details": null
                                },
                                {
                                        "type": "subTitle",
                                        "content": "직무명(ex. 프론트엔드 인턴)",
                                        "details": null
                                },
                                **{
                                        "type": "jobTitle",
                                        "content": "주요 업무 (ex. 프로그래머스 데브코스 수강 페이지 신설)",
                                        "details": [
                                                *{
                                                        "type": "jobDuration",
                                                        "content": "2022.09 ~ 2023.12",
                                                        "details": null
                                                },
                                                {
                                                        "type": "jobDescription",
                                                        "content": "토스비지니스 앱 초기 구현(E2E 암호화, JWT 인증), 개발 환경 구성 및 서비스 개발 방향 설정, React Native Remote bundle Versioning 정책 설계",
                                                        "details": null
                                                }
                                        ]
                                }*
                        ]
                }
        ]
}

문제점

1. 프론트에서 API 연동 부분이 모두 수정이 되어야 함
2. 하나의 블럭에 대해서 다수의 Insert Query가 나간다
   • Insert Query의 순서를 잘 맞춰서 보내야 한다
3. 타입을 무조건 String으로만 지정
   • 현재 도메인 내부에 Boolean, LocalDateTime등 과 같이 여러 타입이 있고
   • 타입 별로 검증 로직이 있는데 String으로만?!?!?

---

 

고민 내용 정리

1번 문제점에 대한 고민 내용

• 위 나온 구조는 오로지 DB에 저장하기 위한 엔티티로만 사용을 하고 DTO의 변경은 없도록 진행

2번 문제점에 대한 고민 내용

• 해당 고민은 Database의 Auto_Increment를 사용하면서 저장 후 Id를 받아오고 다시 해당 Id를 부모 Id로 가지는 자식 엔티티를 만들기 때문에 생긴 문제점이다
• Id를 서버 내에서 직접 만들어서 적용해주는 방법으로 bulk Insert를 진행하면 하나의 Insert Query를 통해 진행을 할 수 있다
  • 하나 고민해야 할 점은 만일 서버가 늘어날 경우, 동시성으로 인한 Id 값이 중복으로 들어 갈 경우

3번 문제점에 대한 고민 내용

• 검증 로직은 도메인 로직이지 엔티티 로직이 아님!..
  

  

  • 도메인과 엔티티의 결합을 분리를 해보면?!?
    • 검증 로직은 도메인에 그대로 유지 하면 된다
  • 음.. 그럼 단순 엔티티만을 변경하는 거지 API를 찍어낸다라는 문제는해결이 안될 거 같은데
  • 아니면 위 구조를 DTO, Entity 두 부분에서 모두 사용을 하면?
   

 

참고

[Spring JPA] Self Join 셀프조인

[Spring JPA] Self Join 셀프조인

셀프로 양방향 연관관계 관련 질문입니다. - 인프런 | 질문 & 답변

셀프로 양방향 연관관계 관련 질문입니다. - 인프런 | 질문 & 답변