안녕하세요. 강의 잘 듣고 있습니다. 입문자들은 역정규화보단 정석적인 방법대로 하는 게 좋다고 하셨는데, 실제 현업에서 오래 일을 하셨던 분들이라 해도 뭔가를 처음 설계할 땐 중복을 없애는 방식으로 설계하고, 실제로 성능 등에 문제가 생기면 그때 역정규화를 고려하나요? 역정규화 자체가 처음 설계 때는 잘 안 하는 건지 궁금합니다.

Choose Category의 UI를 보면 Create New라는 항목이 보입니다. 즉 내가 원하는 카테고리를 추가하는 기능이 있는 것으로 보이고, 내가 추가한다고 남에게도 그 항목이 보이면 안되므로, 혹은 기존의 카테고리의 아이콘이나 색깔을 바꾼다고 남에게도 적용되면 안되므로 categories 테이블에는 사용자의 FK값이 있어야 할것으로 판단됩니다. 이렇게 할 경우, tasks 테이블에서 category의 FK와 사용자의 FK를 받게 될텐데, 외래키로 받은 category에도 사용자의 FK가 포함되어 있어서 사용자 FK정보를 두 번 갖게 되는것 같습니다. 물론 task나 category에서 한 번 지정된 사용자가 변경되는 일은 없을 것으로 보이지만, 그래도 엄밀히 말하면 데이터가 중복이 되는 것이 아닌지 궁금합니다. 

강의에서 중간 테이블이, 1칸에 1개의 정보가 불가할 때라고 듣기도 했고N:M의 관계일때는 반드시 중간 테이블을 제작해야 한다고도 들었습니다.저 두 가지의 경우가 같은건지 궁금합니다.N:M 관계가 아닌데도 중간테이블이 만들어질 수도 있나요?

안녕하세요! 강의 재밌게 잘 듣고 있습니다.투두리스트 실습 중 궁금한 부분이 생겨서 질문 남깁니다.저는 UI를 보고 앱 세팅에 관련된 데이터도 저장해야 된다고 생각해서 app_colors, app_typographies, app_languages 세 가지 테이블을 만들었습니다. 하지만 강의에서는 이 데이터를 따로 저장하지 않으셨는데 저장하지 않은 이유가 궁금합니다.

배운 내용을 적용해보면서 궁금한 점이 생겨 질문드립니다.게시판 특성상 계속해서 게시물이 쌓이게 되어 데이터의 양이 늘어날 것이라 생각합니다.일반적으로 게시글 상세 페이지로 들어가기 전에 페이징된 게시물 리스트를 보면 해당 게시글의 제목, 조회 수, 좋아요 수 등이 표시되기도 하는데그렇다면 보통 현업에서는 각각의 좋아요 수 쿼리와 조회 수 쿼리를 날려서 많은 데이터들을 그때그때 full scan하도록 하는지 아니면 역정규화를 수행하여 원래 테이블에 좋아요 수나 조회 수 컬럼을 붙여 넣는지 궁금합니다.

True, False 같은 BOLEAN type을 안쓰고 TINYINT type을 사용하는 이유가 궁금합니다

ㅠㅠ  

안녕하세요 수업을 듣다가 궁금한게 생겨서 질문드립니다~서브 태스크 설계는 대댓글과 같은 계층형 구조로 가져가면 될까요?무한대댓글(네이버 카페 대댓글 구조)일 때 보통 db 설계를 어떻게 가져가나요?찾아보니 인접리스트랑, 클로저테이블 등 db 패턴이 있다는데 어떤 형태로 가져가는지 궁금합니다!

강의를 보다가 궁금증이 생겨서 질문합니다.만약 로그인 안 한 사용자(회원X)도 볼 수 있는 게시글이라고 할 때, 조회수를 어떻게 해야하는 건가요?로그인 한 사람(회원O)만 게시글을 볼 경우 중간테이블을 만들어 이미 봤다면 조회수를 안 올리기 위해 만든 다는 것까지는 이해했습니다.제가 생각한 방식은게시글에 컬럼에 로그인 안 한 사용자의 조회수 넣기(그냥 수로 관리)로그인한 사용자의 경우는 중간테이블로 조회수 관리 데이터를 따로 관리해서 이 둘을 합산해서 총 조회수로 만든다 인데제가 너무 복잡하게 생각한 건지, 다른 좋은 방법이 있는지 궁금합니다

안녕하세요 강의 잘 듣고 있어요 다 들으면 도움이 많이 되고 설계가 재밌어 질 거 같습니다.궁금한 점은 두 엔티티 A, B의 관계를 파악할 때 무조건 처음에 하나의 A, 하나의 B 이렇게 하나의를 붙히고 생각하면 될까요? 아니면 여러개의 A 이렇게도 생각 할 수도 있을 거 같아서요

몽고디비에서 mongoexport를 사용하려하는데 데이터베이스 자체의 update를 사용하지 않고 mongoexport 사용시 field의 value값을 수정하여 csv로 export하는 방법이 있을까요?