User와 Position

[shindong96]

현재 User의 희망 직무를 저장하는 기능을 구현하려합니다. 그런데 2가지 고민사항이 있습니다.

1. 저희 서비스는 희망 직무에 기존에 있던 Position뿐 아니라 직접 입력이라는 부분이 존재합니다. 직접 입력된 직무의 경우 Position 테이블에 저장할 수는 없습니다. 만약 저장하려면 관리자가 저장한 Position과 사용자의 개인적인 Position을 구분해줘야합니다.

2. 희망 직무가 1개만 입력가능하다면 User 테이블에 Position의 PK를 넣어두면 되지만 여러개라면 User와 Position 사이에 다대다가 형성되기에 관계 테이블이 필요합니다.

어떻게 풀어가는게 좋을까요?

[kyukong]

1. 사용자의 개인적인 포지션을 테이블에 저장하게 된다면, 나중에 기능이 확장되었을 때 개인 포지션은 제외하고 사용될 것 같습니다. 만약 공고 필터링 기능에 사용하게 된다면 데이터의 정확도를 위해 관리자의 포지션만 사용될 것이고, 그럼 개인 포지션은 존재하는 의미가 퇴색됩니다. 직접 입력 기능 자체를 없애고 정식적으로 등록 요청을 보내 관리자의 승인을 거쳐가야 한다고 생각합니다.
   -> 사용자의 개인적인 Position 저장 X

2. User 에 List 을 관리하게 되지 않을까요?? 어떤 문제인지 잘 모르겠습니다!

[shindong96]

2번은 도메인 관점이 아닌 테이블을 얘기한겁니다!!

[kyukong]

아앗.. 그러네요 user_positions 등의 중간 테이블이 필요해보입니다. User 와 Position 은 별도의 테이블로 분리하고, user_positions 테이블에서 각각의 아이디값을 보유하고 있어야 할듯합니다..

[Seongwon97]

1. 저도 해당 부분에 대해 고민이었습니다. 직무라는 설정을 만든게 사실상 추후 추가할 공고 기능을 위해 존재하는 값이라 생각하는데, 직무 입력을 사용자로부터 받게 된다면 공고 기능의 이점을 얻기 힘들 것이라 생각됩니다.. 그래서 직접 입력을 없애고 직무를 세분화하는게 좋지 않을까?하는 생각이 드네요😭

   현재 잡코리아의 경우 아래와 같이 더 다양하게 나뉘어져 있더군요..!
   

2. 저는 개인적으로 해당 설정도 공고 기능에서 희망 직무 공고 추천 기능을 고려한 것이라 생각되는데요..! 좀 뒤에 만들 기능이긴하지만 팀원들과 이야기를 해볼까요??

[shindong96]

좋습니다!

[Byeongju-Kong]

저는 전체 Position(운영 측에서 관리하는 직무)들을 응답하는 API를 개발했는데, 그때 Application의 Position 연관관계를 줘야하는지에 대한 고민을 했는데요. 해당 도메인과 연관관계를 맺을 필요는 없다고 생각이 들더라고요. Application이 쌓일 때마다, Position 값을 변경할 수도 없는 노릇이고..
만약에 Application이 Position의 pk를 fk로 가지고 있을 때, 만약에 Application의 직무명이 변경된다면 Position 새로운 Row를 쌓아야할테지요..(해당 Position 데이터는 범용적으로 여러 곳에서 공유할 것이기 때문에)

그런데, 사용자의 Position은 운영자가 관리하는 Position 중에 택 1 혹은 중복 선택을 한다면... 연관관계를 맺어도 된다고 생각합니다!
다대다 테이블을 만드는 것도 별다른 문제가 없어보이네요! 그것이 필요하고 요구사항이라면 만들어야 한다고 생각합니다!