[TIL] Day 33 : 정답이 없는 개발

1. users 테이블을 로그인 아이디(또는 이메일주소)와 비밀번호만 담긴 auth와 나머지 정보가 담긴 users로 쪼갤지 말지

2. users 테이블을 자주 변경하지 않을 것 같은 email, 비밀번호 등이 담긴 users와 자주 변경할 것 같은 닉네임, 프로필 이미지, 자기소개가 담긴 userInfos로 쪼갤지 말지

3. likes 테이블을 하나로 관리할지, post_likes와 comment_likes로 나눠서 관리할지

• likes 테이블을 하나로 관리한다면 해당 like가 post에 속하는 건지 comment에 속하는 건지를 어떻게 구분할지 (enum을 쓸지, 아니면 그냥 post_id와 comment_id를 다 넣고 post에 속하는 거면 comment_id를 null을 넣어 처리할지)
  -> enum을 썼을 때의 단점:

		to_which 		enum(POST, COMMENT)
		to_which_id		int

• 이런 식으로 한다고 했을 때 to_which_id가 post_id가 될 수도 있고, comment_id가 될 수도 있기 때문에 to_which_id의 relation을 정해줄 수가 없다. (두 군데에 동시 지정 불가능)

4. likes의 개수를 세는 일이 엄청 자주 발생할 것이기 때문에 (뉴스피드 조회, 클릭, 댓글 확인 등) 그때마다 일일이 DB에서 조건에 맞게 찾고 필터링해서 개수 세고 하는 것은 너무너무나 비효율적인 일이다.
   따라서 posts 테이블과 comments 테이블에 likes 필드를 추가해서
   좋아요 누를 때마다/취소할 때마다 likes 개수를 +1 또는 -1 하는 식으로 처리하는 게 나을 것 같다.

• 그럼에도 likes 테이블을 남겨두면 좋은 점은, 단순히 likes 개수 표시만 할 거면 상관없지만, likes에 마우스를 갖다대거나 눌렀을 때 누가 likes를 눌렀는지를 알 수 있으려면 likes 테이블도 별개로 관리하는 게 필요하다.

• 대신, posts 또는 comments의 likes 필드의 값에 ±1을 하는 것과
  likes 테이블에서 row를 create/delete 하는 것을
  transaction으로 묶어서 처리해야 한다.

5. url을 depth를 여러번 타고

• /post/:postId/comments/:commentId/likes 이런 식으로
  n-depth로 종속관계를 확실히 표현할지,

• /post/:postId
  /comments/:commentId
  이런 식으로 1-depth 까지만 해서 역할 구분을 확실히 할지