Closed ShinsRo closed 4 years ago
아직 회사라 집 가서 코멘트 남길게요~
인증에 필요한 (login 에 필요한) 필드와 아닌 필드 (job, nickname 등) 은 나눠야합니다.. 인증에 필요한 애들은 로그인 말고는 안쓰니까요.
그리고 role 이 있는데, 시큐리티 쓴다면 Role은 다른 테이블에 생깁니다. User , User_role, role 세개의 테이블이 생기고 거기에 저장되요.
정리
category 만 봐서는 이게 어떤거에 대한 카테고린지 모르겠어요. 변경이 필요합니다.
그리고 member_category의 fk 필드 이름은 member_id 가 맞을 것 같네요.
카테고리는 계층 구조라... 현재 상태로는 계층구조를 표현할 수 없습니다.
'직군'이 루트이고, 그 아래 세부 직무가 계층적으로 꼬리물 수 있도록 구조를 짜야할 것 같습니다.
대댓글을 떠올리면 될 것 같은데, 자기 참조식으로 테이블 구성하시던지, 1차 2차 세부 직군만 나누시던지 하면 될 것 같습니다.
템플릿에 설정된 기한 내에 각자 다르게 설정할 수 있어야 합니다.
Mission이 아니라 Goal 로 변경해야할 것 같습니다. 기획안에 골이라 쓰였으니까요.
또 GoalTemplate 가 따로 있고, Goal, Member_goal, Member 가 서로 연관되어 있어야합니다.
그래야 GoalTemplate 수정해도 영향을 안받습니다.
Goal에 GoalTemplate id로 FK를 두면 될거 같고요.
좀 더 대대적으로 다시 논의를 해야할 것 같긴한데 일단 4가지 의견 먼저 올립니다.
글구 #1 이표시는 이슈 링크라서 #에 하나 띄우고 문자 넣어야 헤드라인이 됩니다
@hscom96 @ian-siotman
pm님이 참여하는 사람마다 끝나는 시기가 같은지, 각자 달라도 되게 설정하기로 했었나요? 요 질문에 대해...
각 템플릿 당 기간 단위(1주일, 1개월, 6개월 등)를 픽스하지 않습니다. 오프너가 기간 자유롭게 설정(시작일~마감일)
또한 새로운 Goal을 추가하는 사람(오프너)이 기간을 설정할 경우, '기간 고정 옵션' 을 토글 버튼으로 넣어 고정여부를 설정할 수 있게 할 생각입니다.
'기간 고정 옵션 - True' : 해당 Goal을 담아가서 오프너가 아닌 타 사용자가 커스텀 할 경우 기간 수정이 불가능함을 말합니다(오프너가 초기 설정한 기간 그대로 받아서 진행).
'기간 고정 옵션 - False' : 해당 Goal을 담아가서 오프너가 아닌 타 사용자가 커스텀 할 경우 기간 수정 자유롭게 가능(기존 템플릿 기간 내 기간이 아니어도 상관없습니다!)
수정사항 반영했습니다
인증에 필요한 테이블 분리 좋은 의견인것같습니다! 근데 제가 스프링 시큐리티 사용한 프로젝트 db 확인해보니 Members_role 한 테이블만 생성되던데 두 테이블 생성되는거 맞나요?
자기참조로 했고 sup_category_id(상위카테고리 참조)라는 속성을 추가해봤습니다. ERD에는 자기참조 관계선이 이상하게 그려지는데 무시해주세요
GoalTemplate 테이블 말씀해주셨는데 따로 있을 필요성을 잘모르겠습니다. 기존 Goal에 참여하는 형태 아닌가요? custom할 정보는 todo말고 있을까요 그리고 Goal 테이블이 수정이 발생할 속성은 없어보입니다.
정현님의 의견에따라 순서 관련 속성 'priority' 추가했습니다.
@hscom96
여기 두 테이블에서 잘못쓰인 mission > goal 로 잘 수정해주세용!
category의 sup? sub category 인가요? 직무 직군을 나눈거라면 sub category에 대한 테이블도 있어야 하지 않나 싶네요
개발 디자인 이라는 큰 직무라는 카테고리가 있을거고 각각 세부직무가 있을텐데 각각을 main, sub category 라고 한다면 member category에 이어져야 하는건 sub category 이고 각각의 Goal은 main과 sub category 정보를 둘다 가지고 있어야 된다고 생각합니다
내 관심직무가 '디자인 -> ux디자이너' + '개발 + 프론트 엔지니어' 이런 경우가 있어서
sub 즉 하위 카테고리가 아니라 sup = super = 상위 카테고리입니다!
따라서 하위 카테고리로 설정하면 말씀하신 main과 sub category 정보를 둘다 가지고 있게됩니다.
그럼 super 카테고리는 따로 저장하는게 아니라 직접 칼럼에 입력한다는 뜻인가요? 나쁘진 않지만 추후 직군이 추가되었을때 확장 가능성이 충분할까요?
괜찮으면 말구! ㅎㅎ
확장가능성은 문제없지않을까요?! 그냥 sup_category_id로 참조만 하면되니깐요 ㅎㅎ
sup category 는 테이블이 따로 없는건가요? 아님 내가 헷갈리는 건가
아 id 라고 써있구나 저건 잘못봄 근데 테이블이 안보여서 ㅎ..
네 저 설계에서는 sub category에대한 테이블은 따로없어요
음 아 키가 꼭 숫자일 필요는 없구나 ㅇㅋㅇㅋ 최고 ><
음 문득든 생각인데 1차카테고리, 2차 하위 카테고리 명확히 구분되도록 카테고리 테이블에 'level' 이라는 속성을 추가할까요?
같은 테이블에 저장한다면 필요할거 같아요
사실 전 따로 두는게 더 보기 편하지 않나 생각이 들기도 하지만 다시 생각해보니 카테고리 레벨이 늘어날 경우도 있을 수 있으니 level도 괜찮겠네요
현재까지 종합본입니다 더 의견주세요
category't' 빼주세용 오타아닌가?
역시 꼼꼼하셔 ㅠ
와 pm님 예리해 미쳤어
is_thir't'_party > d로 바까주세여
ㅋㅋㅋㅋ 오타 천국
현수킴이 미침ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ열정미쳣다구ㅠㅜㅠㅠㅠㅠㅠㅠㅠ증맬
그건 sup 맞아욤 super=상위!
완벽쓰~완벽쓰bbbbbb
근데 이렇게 두명이나 헷갈렸다는건 직관적이지 않은 네이밍인거 같아요
네이밍 추천해주세요ㅎㅎㅎ
저는 그냥 super_category_id 써도 될거 같아요 가장 직관적이고
아 좋습니다
Member_category 는 오해의 소지가 많은 것 같아요.
마치 유저를 분류하는 어떠한 값들을 위한 것 같습니다.
Job_group 정도가 알맞을 것 같아요.
category는 job_class 정도가 맞을것같고요
@hscom96
아 그리고 스프링 시큐리티에서 테이블 3개 생성 맞아요
Goal_template 가 필요한 이유는 그 템플릿에서 복사해와서 goal이 되야 다른 사람의 goal에 영향이 없기 때문입니다
erd 짜봤는데 검토해주시면 감사합니다.
erd에대해 설명이 필요한부분은
1 Members 테이블
name- 닉네임 uid - 유저아이디 (소셜로그인이라면 kakaoId로 채우면 될것같습니다.) passwd - 비밀번호 ( 소셜로그인만 한다고하면 사실 필요한 속성은 아니지만 로컬로그인의 확장가능성을 고려해서 추가) provider - kakao,facebook,google,local 등 중 어느 회원인지 image_path - json형태든 배열형태로 저장하면 좋을것같습니다. job - 직군 (개발/디자인)
2 category 테이블
관심분야 테이블입니다. (UX디자인, 웹디자인, 영상디자인 등등등) Member와 category간에는 다대다 관계가 형성되므로 중간에 Member_category 테이블 만들었습니다. Mission테이블 간에는 1:1 관계이므로 바로 이었습니다.
3
start_dt, end_dt 즉 목표 시작날짜 끝나는 날짜인데 이 부분은 어떤식으로 넣을지 다시 생각해봐야 할것같습니다. 그때 pm님이 참여하는 사람마다 끝나는시기가 같은지, 각자 달라도 되게 설정하기로했었나요? 일단 Mission_join 테이블에 넣고 Mission 테이블에도 넣었습니다.
4 Mission table
join_count - 참여자 수 속성인데 매번 조인해서 참여자수 구하는것보다 join_count속성을 두어 trigger를 쓰든해서 처리하면 더 효율적일것같습니다. 마찬가지로 목표 달성률 같은경우도 매번 조인해서 계산하는것보다 Mission_join테이블에 관련 속성을 두면좋을것같습니다.
5 기타
승신님이 예전에 Mission_join부분이랑 Todo 테이블과 합치자고 했는데 그렇게 되면 join을 안해도되지만 jpa로 페이징처리하기 힘들고, 생성날짜 정렬 같은 처리를 하기 힘들지않을까요? 무엇보다 RDBMS적인 설계는 아닌것 같은데 어떻게 생각하신가요