사용자 테이블 과 팔로우 테이블 과의 관계를 다대다 관계라고 할 수 있을까요?중간 테이블로 풀어내는 다대다 관계랑은 조금 다른 것 같아서 이런 경우에는 명칭이 어떻게 되는지 궁금합니다

안녕하세요 강의 잘 듣고 있습니다제가 현재 채팅 프로그램을 만들고 있는데 채팅 서버가 하나이면 굳이 레디스를 사용할 필요가 없겠네요?

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

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

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

강의에서는 fastapi 앱 서버, dash 앱서버 각각 실행을 한 상태에서 dash에서 request를 수행하셨는데dataframe을 사용하지 않고 fastai 결과 dictionary 를 받아서 dashboard를 그리는데 유리한 부분이 있을까요? (속도 측면?)fastapi와 dash를 같이 사용할 때 일반적인 방법이나 추천하는 방법이 따로 있을까요?

안녕하세요 강사님 새해 복 많이 받으세요!개인적으로 궁금한 점이 있어 질문을 드리게 되었습니다.멀티 모듈 및 멀티 모듈 셋팅에 관한 지식을 공식 문서를 보시고 영어를 해석 하거나 혹은 번역 기능을 활용하여 직접 테스트를 하시면서 습득하셨는지 아니면 도서나 타 강의로 습득을 하셨는지 질문 드리고 싶습니다! 간혹 다른 타 강의에서 질문을 드릴 때 공식 문서 링크를 주셔서 공식 문서를 보았는데 봐도 내용이 너무 방대하고 어떻게 해야 할지 잘 모르겠더라고요 그러면 그냥 실력이 부족한 것일까요? 아니면 제가 제대로 시간을 제대로 들이지 않고 탐독하지 않은 것일까요? 제가 해당 강의에서 개인적으로 느끼기에는 멀티 모듈 및 세팅 방법, 디테일 한 내용이(apply piugin 설정, bootJar.enabled=true, jar.enabled=true 같은) 일반적인 지식이 아닌 생소한 지식이라고 생각을 했습니다.(일반적인 지식이었다면 비전공자여서 그랬나 봅니다 ㅠㅠ...) 비전공자로서 개발 공부를 하면서 느끼는거지만 디테일한 내용이나 검색으로 잘 찾아지지 않는 지식들과 새로운 지식들은 어떻게 습득해야할지 방법을 잘 모르겠어서 계속 헤메는 느낌이 있어 질문 드립니다!

안녕하세요. 과제전형을 준비중인데 강의듣고 많은걸 깨우쳤습니다. 잘 배우고 있는 중입니다.그런데 올려주신 코드(TestController.java)를 실행했을 때 로컬 주소로 NotFound가 나더라구요. 코틀린코드로 변경하면서 공부중인데 제 코드가 문제라 생각하다가 원본 코드를 한번 돌려봤는데 같은 현상이 일어나서 혹시 더 설정해 줘야 할게 있을지 여쭤봅니다.restClient를 의심했다가 public api 가 동작하는 것을 보고 역시 라이브러리 문제는 아닌거 같더라구여. 

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

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

검색어를 http로 했더니 위와 같이 author 배열이 비어 있는 경우가 있어서   author 의 index 0 으로 값을 꺼내는 경우 IndexOutOfBoundsException 발생하므로 적절한 처리가 필요하니 참고 바랍니다.

강의를 커밋으로 끊으면서 만드신거 너무 좋습니다. 강의도 길어지지도 않고 깃 사용법도 좀 더 배울 수 있구요. 단지 커밋 메시지랑 브랜치명이 조금씩 안 맞는 부분은 있습니다. 😄

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

ㅠㅠ  

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

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

비즈니스 로직만을 담당하는 BookApplicationService 를 두는게 새롭고 좋은 구조 아닐까 생각이 들어서 제 생각이 맞는지 궁금해서 여쭙습니다.  Query 이름의 서비스는 조회만을Command 는 등록, 수정, 삭제 담당하는 것이고 또한 이런 서비스 구조가 순환참조 발생 가능성도 줄일 수 있겠죠? p.s 강의 잘 듣고 있습니다. 처음 겪어보는 내용들이 많아서 재밌고 배울게 많네요. 강의 빨리 더 내주십시오.

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

모의과제 소개 영상에서 보여주시는 모의과제 요구사항 pdf 파일은 업로드가 안 되어있는 걸까요?

안녕하세요. 지식공유자님!데이터베이스 연결 강의를 보고 질문 드립니다.서비스를 command와 query로 분리하고 있는데요.이것을 cqrs 패턴으로 부른다고 알고 있습니다.이게 좋다고는 들었는데, 정확히 왜 그런지는 잘 모릅니다.만약, 면접관이 "cqrs에 대해서 아느냐? 왜 이렇게 구현했느냐?" 라고 묻는다면, 지식공유자님께서는 어떻게 답변하시겠습니까?감사합니다.