Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Dev Log] 스키마 작성간 발생한 고민 #120

Open
junu0810 opened this issue Dec 27, 2021 · 0 comments
Open

[Dev Log] 스키마 작성간 발생한 고민 #120

junu0810 opened this issue Dec 27, 2021 · 0 comments
Assignees

Comments

@junu0810
Copy link
Contributor

어떤 부분을 진행간에 깨달았나요?

  • DB설계간 스키마를 작성할때 사용자의 사용성과 개발자의 편의성을 고려하여 설계하는 방법을 느꼈다.

프로젝트에서 꺠달은 점은 무엇인가요?

  • 아래는 변경전의 스키마이다.

2021-12-14_8 45 48

DB 스키마를 기획하면서 단지 DB를 각 컨포넌트마다사용해야 된다는 생각에 많은 부분을 세분화하여작업을 한 경우가 없지않아 있다.
그러다보니 프로젝트 대기명단과 프로젝트 진행면단을 따로 테이블로만들어 두었다.
하지만 팀원들과 소통을 한 결과 불필요한 테이블이라는 의견이 나왔고 토의를 거친결과 이미 프로젝트 진행한 인원의 명단은 따로 테이블 관리를 할 필요 없이 프로젝트테이블에서 userID를 이용해서 확정된 인원들을 관리하기로 하였다.
또한 진행을 해보니 유저의 스택을 간과하였고 스택의 이름이 모인 테이블을 따로 만들어 거기서유저의 아이디를 이용한 Join테이블을 활용해서 유저의 기술 스택을 관리하기로 하였다.
실제로 프로젝트를 진행하면서 회원정보와 프로젝트를 관리할때 훨씬 편리했다는것을 깨달았다.
예시로 프로젝트에 대기중인 유저를 불러올때 프로젝트테이블에서 유저ID를 불러 유저정보를 찾을수도 있었고 프로젝트의 정보도 불러올수 있었다. 만약 이전의 결과로 진행했다면 프로젝트테이블에서 프로젝트 정보를 불러오고 waiting테이블에서 대기중인 userID를 이용해서 users테이블에서 유저정보를 불러오는등 다소 복잡한 과정을 겪었을 것이다.

즉. 활용하는 곳 하나당 테이블을 만드는 것이 아닌 역할이 겹치거나 하나의 테이블로 관리가 될경우 최대한 진행방향을 테이블을 줄이는 쪽으로 하여 상태관리를 용이하게 하는것이 중요하다는것을 깨달았다.

  • 팀원들과 토의를 진행하고 만들어낸 스키마이다.

68747470733a2f2f63646e2e646973636f72646170702e636f6d2f6174746163686d656e74732f3931393737323633303235353533343038332f39323039

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants