그룹웨어 시스템 ERD 설계 개요

일친 시스템의 ERD를 설계해보았다. 쇠뿔도 단김에 빼라고 기획을 하니 ERD도 금방금방 나온거같다. 평소엔 좀 더 딥하고 큰 범위로 ERD를 설계했는데 이번 프로젝트의 목표 기한은 길어야 한달, 웬만하면 2주로 끝내고싶기에 최대한 간단하게 기획했다.

1. 엔티티 목록

User (회원)

• id : BIGINT (PK)
• username : VARCHAR
• email : VARCHAR
• password : VARCHAR
• role : VARCHAR
• created_at : DATETIME

User_Profile (유저 프로필)

• id : BIGINT (PK)
• user_id : BIGINT (FK, User)
• department_id : BIGINT (FK, Department)
• full_name : VARCHAR
• phone : VARCHAR

Department (부서)

• id : BIGINT (PK)
• name : VARCHAR
• description : TEXT
• user_id : BIGINT (FK, User, 부서장)
• tel : VARCHAR

Project (프로젝트)

• id : BIGINT (PK)
• owner_id : BIGINT (FK, User)
• name : VARCHAR
• description : TEXT
• webhook : TEXT
• created_at : DATETIME
• state : VARCHAR

Project_Member (프로젝트 멤버)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• user_id : BIGINT (FK, User)
• role : VARCHAR
• joined_at : DATETIME

Task (업무 태스크)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• assignee_id : BIGINT (FK, User)
• title : VARCHAR
• description : TEXT
• state : VARCHAR
• due_date : DATE
• created_at : DATETIME

Issue (이슈)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• reporter_id : BIGINT (FK, User)
• task_id : BIGINT (FK, Task)
• pr_id : BIGINT (FK, Pull_Request)
• state : VARCHAR
• title : VARCHAR
• description : TEXT
• created_at : DATETIME
• updated_at : DATETIME

Pull_Request (PR)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• title : VARCHAR
• url : VARCHAR
• status : VARCHAR
• creator_login : VARCHAR
• created_at : DATETIME

Comment (댓글)

• id : BIGINT (PK)
• content : TEXT
• target : VARCHAR — 댓글 또는 이슈, 태스크 대상 구분
• target_id : BIGINT — 대상 엔티티 ID
• created_at : DATETIME
• user_id : BIGINT (FK, User)

2. 관계 정리

• User ↔ User_Profile : 일대일 관계

• User ↔ Project : 프로젝트 소유자 (1:N)

• Project ↔ Project_Member : 다대일 관계 (프로젝트별 여러 멤버)

• User ↔ Project_Member : 다대일 (회원이 여러 프로젝...)

• Project ↔ Task : 일대다

• User (assignee) ↔ Task : 일대다

• User (reporter) ↔ Issue : 일대다

• Project ↔ Issue : 일대다

• Issue ↔ Pull_Request : 일대일 또는 다대일 (ID 연동)

• Comment ↔ 대상 (이슈, 태스크, 댓글 등) : polymorphic 형태로 대상 ID와 구분해서 저장

ERD 설계, 왜 이렇게 했을까?

• 유연성과 확장성 중심의 설계

  • 최대한 유연성과 확장성에 초점을 맞춰서 설계해보았다. 앞으로 프로젝트가 어떻게 변하든, 쉽게 대응할 수 있게 만들어 본것이다. 예를 들어, 핵심 개체들 관계는 너무 복잡하지 않게 딱 필요한 것만 딱 넣었으며, 새 기능이나 필드가 추가될 때도 어렵지 않게 고치거나 확장할 수 있게 설계하였다.

• FK 제약 최소화 및 자바 엔티티 중심 설계

  • 일단 DB에서 강제로 연관관계를 묶기보단, 자바 쪽에서 관리하는 게 훨씬 편하다. 실제로는 자바(Spring Data JPA, Hibernate 쓰는 애들)에서 데이터 무결성을 체크하게 하고, DB는 그냥 연결된 관계를 일부러 강하게 묶지 않게 되면, 물리 테이블에 저장된 정보를 수정하거나 제거할 때 제약조건에 걸리지 않아 개발 할 때 여러모로 편하고 확장성도 보장된다.

• 폴리모픽 연관 관계 고려

  • 댓글 같은 경우는 대상이 여러 가지일 수 있어서, ‘이벤트 대상이 이슈야? 태스크야? 아니면 댓글 자체야?’ 하는 문제를 해결하려고 target과 target_id라는 필드 하나로 컴팩트하게 만들어서 써보았다. 이렇게 하면 추후에 기능을 더 늘리거나 다른 대상도 쉽게 연결할 수 있음으로 따로 연관관계를 새롭게 맺지않아도 되어 확장성이 좋다!

• 외부 시스템 연동 및 연관 정보 관리

  • Pull Request(PR)는 GitHub 등 외부 시스템과 연동하는 경우가 많기 때문에, creator_login과 같이 문자열로 저장하는 방식을 선택했다 실제 유저 테이블에 저장되지 않는 정보기 때문에 문자열로 그때그때 보여주는게 나아보여서? 채택한 방식
  • 아마 추후에 필요시 별도로 깃헙 계정 연동 테이블을 만들어, 외부 계정이나 사용자 정보와 연동하는 것도 가능하도록 추가 개발해서 API 연동 시 유연성을 확보할 수 도 있을 것같다.

• PR 캐싱 전략과 데이터 일관성

  • PR 정보의 경우 깃허브에 올라간 정보를 직접 API로 불러올 예정이다. 이때 호출이 너무 잦게되면 해당 api측에서 부하가 걸릴수도, 호출 제한이 걸릴지도 모르는 일이다. 이에따라 호출을 최소화하기 위해 PR정보를 불러올 때 마다 호출하기보단 캐싱처리로 중복데이터는 서버에 저장된 데이터로 보여줄 예정이다. 다만 새로운 데이터가 있을 경우 새롭게 받아와야하는데 이 경우는 캐시 키를 뭐로 줘야할지 아직 고민중이다.