week2_3일차_PR

주요 작업

• sql과 nodejs 연결 ✅ 2024-08-28
• erd 작성 ✅ 2024-08-28
• 함수형 변경 리팩토링(계속 진행중) ✅ 2024-08-28
• api별로 만들기(진행중)

학습 키워드

• sql문 ✅ 2024-08-28
• sql workbench ✅ 2024-08-28
• ssh 터널링 ✅ 2024-08-28
• Locale ✅ 2024-08-28
• MVC 패턴 ✅ 2024-08-28
• Primary Key, Foreign Key, Unique Key ✅ 2024-08-28
• https://luxurious-share-af6.notion.site/2-bfaf16a16f8743eb9ee0e08af52673be?pvs=4

고민 및 해결과정

ERD 설계

나는 이제까지 쭉 프론트엔드만 하던 터라 데이터베이스를 설계하는 것 자체가 익숙치 않아 이 점이 매우 어려웠던 것 같다. 기존의 데이터 구조나 자료형 등을 선택하는 과정에서는 해당하는 문제에만 집중하면 됐기 때문에 데이터베이스의 의존성과 같은 점을 생각해볼 기회가 거의 없었는데, 이번에 기본 키, 외래 키 설정 등 신경 쓸 요소들이 많은 만큼 erd 자체를 설계하고, 이러한 값들을 어떻게 sql문으로 효율적으로 가져올 수 있을까에 대해서 많이 고민했다.

신경 쓴 요소들로는

• 유저를 따로 둘 것인가?
• 히스토리는 어디에 관계를 두어야 하는가?
• 필드명은 무엇으로 정해야 하는가?
• type의 varchar 또한 어느정도까지 허용해야 하는가?
• 히스토리는 각각 action마다 받아야 하는 데이터가 달라야 할텐데, 이를 어떻게 데이터베이스에 넣고 어떻게 가공하여 사용할 것인가? 등에 대한 고민들을 하나씩 해결해가며 ERD를 짜기 시작했다.

이러한 고민들에 대한 해결책으로 나온 ERD인데, 고민거리를 어떻게 해소하였는지를 써보려고 한다.

• 유저를 따로 둘 것인가?
  • 유저를 따로 두어야만 author가 의미를 가질 것 같다고 생각했다. 아마 일부러 author을 둔 이유는 유저를 만든다는 전제 하에 기획서가 작성된 것 같다고 판단하여 간단하게 유저아이디와 이름만을 받도록 했다.
  • 나중에 로그인이나 다른 기능들이 추가된다면, 해당 유저 테이블의 레코드를 추가하면 될 것 같다고 판단하였다.
• 히스토리는 어디에 관계를 두어야 하는가?
  • 히스토리는 유저와 관계를 가지고, action은 기획서에 정의된 등록, 이동, 변경 세 가지 경우만 받을 수 있도록 한 다음, 이에 따라 상세 활동읋 따로 파싱하여 각 action에 맞게 서버에서 가공하면 될 것 같다고 생각했다.
• 레코드명은 무엇으로 정해야 하는가?
  • 레코드명의 경우 최대한 내가 무엇을 가리키는지 명료하게 볼 수 있도록 이름을 작성하였다.
• type의 varchar 또한 어느정도까지 허용해야 하는가?
  • 일반적인 것들은 50자까지 허용하되, 투두카드의 본문이 500자까지 허용되는 만큼 제목과 상세 내용에 예외를 두었다
  • 또한 히스토리의 상세 활동 또한 파싱해서 사용해야 하기 때문에, 글자수가 많이 늘어날 가능성이 있다고 판단하여 임의로 늘렸지만, 합리적인 기준에서 조금 더 손볼 예정이다.
• 히스토리는 각각 action마다 받아야 하는 데이터가 달라야 할텐데, 이를 어떻게 데이터베이스에 넣고 어떻게 가공하여 사용할 것인가?
  • 위에서 말한 것과 같이 action_detail에 필요한 JSON 데이터를 전부 string으로 파싱한 뒤에 이를 가져와서 파싱하고 가공하여 사용하면 되지 않을까 생각했다. 굳이 JSON 데이터가 아니더라도 일반 문자열을 일정 기준을 두고 파싱하여 사용하는 방법도 생각해보았지만, JSON.stringify된 문자열이 된다면 이를 그대로 사용하는 것이 보다 합리적으로 보인다.