문제 2번에서두 그룹의 목록을 중복 제거 없이 모두 합쳐서 조회해라. 라고 문제가 나오는데어째서 distinct를 이용하는건가요? 중복을 제거하고 합치는게 의도였다면 정답에 션과 네이트도 중복이 제거가 돼야 중복 제거가 의도라고 이해할텐데 distinct를 사용한 의도를 잘 모르겠어요

유니크 제약조건에 대해 질문드립니다. 예를 들어 핸드폰 번호당 계정을 하나만 가질 수 있어서 핸드폰 컬럼을 유니크제약을 걸었습니다.특정 회원이 탈퇴할 때 하드 딜리트가 아니라 소프트 딜리트를 하는 정책일 경우, 탈퇴 했던 유저가 다시 가입하게되면 어떻게 해줘야할까요.? 그럼 결국 유니크 제약을 디비에서 없애고, 애플리케이션 단에서 제어를 해야할까요?

안녕하세요COUNT 쿼리에 LIMIT 를 지정하는 이유가 있을까요? 설명해주셨는데 놓친건지 모르겠네요ㅜ

정규화와 정규형을 생각할 때는 자연키를 사용한다는 것을 가정해야할까요?예를 들어,회원 테이블을 회원id (대리키), 아이디(자연키), 비밀번호, 이메일 속성으로 정의할 때, 회원id 는 아이디를 결정하고 (회원id -> 아이디), 아이디는 비밀번호, 이메일을 결정하므로 (아이디 -> 비밀번호, 아이디 -> 이메일) 이행함수 종속이 발생하는 것처럼 보입니다. 이처럼 정규화와 정규형을 생각할 때에는 대리키 개념을 배제하고, 자연키를 기준으로 생각해야할까요?

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.안녕하세요 선생님!지난번에 남겨주신 답변내용을 보면서 전략도입의 배경부터 처리과정까지 복기해보았습니다.그러다가 의문이 생긴 점이 있습니다.1) 의문점Request Collapsing, 캐싱중복적재를 제외하고 캐싱하여 데이터를 추출하는 과정만을 보았을때, 원본과 캐싱 데이터 모두 Redis에서 추출해오는 것인데, 원본추출과 비교하였을때 과정적으로 어떠한 차이점이 추가적으로 있있기에 별도의 과정으로 간주하는 것일까? 즉, "캐싱하여 가지고 오는 과정"과 "원본 데이터 추출"을 따로 보고 계셨기에, 어떠한 차이점이 있는지 의문점이 들었습니다. 2) 의문점이 생긴 이유단순하게 간략히 말씀드리자면,조회수 원본데이터는 Redis에서 가져오는 조회수이고, 캐싱해서 가져오는 것 역시 Redis에서 가져오는 조회수로 보여집니다. 원본데이터가 MySQL과 같은 디스크 조회 비용이 큰 저장소에 들어있는 것이 아니라, 동일한 In Memory database인 Redis에서 가져오는 것이기에 성능/비용적으로 캐싱 데이터를 가지고 오는 것에 큰 이점을 느끼지 못하였습니다. 세부적으로 살펴보았을때,ViewClient에서 원본 데이터를 가지고 오는 경우 아래 로직을 통해 Redis에서 추출합니다.articleViewCountRepository.read(articleId);이떄 key는 view::article::#articleId::view_count 입니다.ViewClient에서 Aspect를 처리하여 캐싱 데이터를 가지고 오는 경우 Redis에서 추출합니다.이때 key는 articleViewCount::#articleId입니다.이 과정에 대해 캐싱을 하는 목적을 생각해보았을때(=원본데이터 추출에 시간이 오래 걸릴 경우 성능이 빠른 다른 데이터저장소를 운용하여 이곳에서 데이터를 추출해오기 위함), 동일하게 Redis에서 추출하는 데이터임에에도 key를 별도로 운용하고, 데이터를 추출하는 과정도 다르게 가져가는(간주하는) 이유가 무엇인지 궁금하여 문의코자 합니다(물론 전체 로직을 살펴보았을때는 기존 대비 중복적재/Request Collapsing 과정을 추가하였기에 당연히 성능적인 이점이 존재하겠지만, 데이터를 가져오는 과정 그 자체만을 보았을때는 의문점이 들었습니다). 이게 데이터를 추출하는 과정이 다르기에, 동일한 key로 운용하면 실무적으로 로직이나 key관리방안이 복잡해져서 관리의 효율화를 위해 나누는 것일까요(즉, 기존과 달리 분산락도 사용하고 중복적재를 방지하기 위해 이용하므로 목적 자체가 다르기에 key 포맷 및 캐싱을 별도로 운용하는 것으로 이해하는 것이 적절한지)? 제가 캐싱의 목적 부터 잘못 이해하고 있는 것일 수 있고, 실무적으로 비용/성능적 유리하다는 의미가 무엇인지 잘못 이해하고 있는 것일 수 있다고 생각하고 있습니다. 그렇기에 챗지피티에게 물어보기보다는 실무적으로 경험이 풍부하시고 그만큼 검증된 선생님의 판단이 더 정확하고 궁금하여 질문드리게 되었습니다. 바쁘신데도 항상 성심성의껏 답변해주시는 선생님께 감사의 말씀 드립니다. 이효균 드림. 

지금 Swagger 적용하기 보고있는데Application.kt 파일 을 작성하는데스프링이 적용이안돼는지 어노테이션 이 원래 빨갛고 노랗게 떠야하는데 안뜨네요강의보고 따라하는중인데 어떻게해야될지 잘모르겠습니다

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요, 선생님! 강의 알차게 잘 수강하고 있습니다.현재 90% 수강 완료하였는데, 어렵고 힘들게 여기까지 온 만큼 저의 역량도 비교할 수 없을 정도로 많이 성장한 것 같습니다.먼저 감사의 말씀을 드립니다.일단 현재 게시글 목록 최적화 전략 구현(64강) 강의를 수강 중인데, 이전의 강의 내용(게시글 조회 최적화 전략)과 비교하였을때 최적화 전략을 수립하는 과정과 관련하여 몇가지 의문점이 들어 질문드리게 되었습니다.의문점) - 게시글/카테고리에 대한 게시글 목록 모두 전략을 나누어야 하는가?의문점이 들었던 과정) - 일단 크게 보았을때, 게시글 내용에 대한 캐싱(articleId)과 게시글 목록(*특정 카테고리, board로 지칭)에 대한 캐싱(boardId)으로 내용을 나눌 수 있을 것 같습니다.- 여기서 드는 제 개인적인 생각은, (일단 전략의 당위성이나 세부적인 내용 상관없이) 캐싱전략을 너무 세세하게, 오히려 성능적 이점보다는 관리적 비용이 더 크게 소모되지 않을까 하는 염려가 들 정도로 배꼽이 더 큰 전략/관리방안을 각각 구분해놓는 것이 아닌가하는 생각이 들었습니다.- 예를 들어, 게시글 목록 최적화 전략의 경우 말씀하신대로 최초 목록 조회 진입 시 보여지는 내용이기도 하고 이는 모든 사용자에게 공통적으로 적용할 수 있는 정책이므로 관리의 당위성이나 책임이 명확하다고 생각하였습니다.- 하지만 게시글 조회 최적화 전략의 경우, 목록 최적화 전략을 수강한 이후에는 "게시글 조회"역시 어떻게 보면 그 게시글을 보고싶은 사용자 일부에 대해서만 보여지는 글이므로..지금처럼 모든 생성 글/댓글/좋아요에 대해 ArticleQueryModel 데이터를 생성하는 것이 비용효율이나 관리효율면에서 과연 올바른 방향인지 다소 의문이 들게 되었습니다. 또한, 이러한 전략수립의 당위성을 떠나서 각 조회기능별로 전략을 구상하는게(단건/목록 등) 수립은 가능하더라도 관리가 힘들 것 같은데, 실무적으로 관리가 가능할지 의문이 들기도 하였습니다.최종 질문)- 제가 올바르게 강의내용을 이해하지 못하여 질문드리는 것 일 수 있기에, 일단 제가 들었던 의문이 선생님께서 생각하셨을때, 타당한 의문일지 궁금합니다.- 타당하다면 아래와 같은 "게시글 단건" 조회 전략을 생각할 수 있을 것 같은데, 혹시 바람직한 전략이 될 수 있을지 고견을 요청드려보고자 합니다.- 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다.[단건 조회전략 구상 방안] 게시글 조회 전략을 만약 구상한다면(세부적인 전략구현은 생략)- 지금처럼 단건 데이터 생성마다 articleQueryModel을 구성하는 것이 아니라, 각 카테고리별 보여지는 1000개의 데이터에 대해 articleQueryModel 데이터를 구성한다. (*게시글을 보는 것도 결국 최신 1000개의 데이터에 대해서만 볼 것이기 때문이다.)- 인기글 데이터 생성 후 해당 인기글에 대한 articleQueryModel 데이터를 구성한다.(*인기글 데이터에 대해서만 단건 조회 트래픽이 몰릴 것으로 예상할 수 있기 때문이다.)읽어주셔서 감사드립니다.

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]안녕하세요 영한님, 강의 정말 재밌게 봤습니다!다름이 아니라 문제와 풀이 3번 문제 "RIGHT JOIN으로 주문 없는 고객 찾기"를 보면 '가입은 했지만 주문 기록이 없는 고객의 이름과 이메일을 조회하는 SQL을 작성하라고 되어있는데, DISTINCT를 붙여 중복을 제거한 행을 조회하는게 맞는게 아닌가 싶어 질문 드립니다!! -- 기존 답안 SELECT u.name, u.email FROM orders o RIGHT JOIN users u on o.user_id = u.user_id WHERE o.order_id IS NULL; -- 제가 생각한 쿼리문 SELECT DISTINCT u.name, u.email FROM orders o RIGHT JOIN users u on o.user_id = u.user_id WHERE o.order_id IS NULL;

만약 카프카를 사용하고 있고 처리 실패하는 경우 retry 큐로 보내서 재시도 하는 방식을 사용하고 있다고 가정하겠습니다. 만약 서버가 메시지를 받아서 처리하던 중에 리밸런싱이 발생했습니다. 메시지를 성공적으로 처리했고 커밋을 하려했지만 리밸런싱이 발생해 커밋을 하지 못했습니다. 그럼 그 메시지는 다른 컨슈머가 다시 받아서 중복으로 처리할 수 있을것 같은데 어떻게 방지를 할 수 있나요..? 찾아보니 인박스 패턴이라는것이 있던데 메시지를 받았을 때 상태를 저장하고 이후에 재시도를 해도 상태값이 있다면 패스하는 방식으로 이해를 했습니다. 하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...?

안녕하세요! 강의 너무 잘 보고 있습니다!강의를 보는 중 궁금한 부분이 생겨 질문드려봅니다!@GetMapping("/callback") fun callback( ... return ResponseEntity.status(HttpStatus.FOUND) .location(URI.create("https://localhost:3000")).build()콜백 함수에 return을 이렇게 작성하셨는데요!만약에 서블릿객체를 이용해서 쿠키를 담지 않고 아래와 같이 하는 방법은 어떻게 보시는지요...?? 같은 동작을 할 것으로 예상은되는데 보편적인 스타일이 궁금합니다 ㅋ.ㅋ;```return ResponseEntity .status(HttpStatus.FOUND) .header("Set-Cookie", "authToken=$token; HttpOnly; Path=/; Max-Age=${60 60 24 * 7}") .location(URI.create("http://localhost:3000")) .build()```

안녕하세요!다른 분 질문에 대한 답변을 보고 기본적인 의구심은 해소되었는데요. 혹시 몰라 확인차 여쭙습니다.09:38 피피티에서요.나머지 연산을 이용해서 물리샤드, 논리샤드를 구분하셨잖아요.제가 이해하기로 나머지가 0이면 1번 샤드, 1이면 2번 샤드...이렇게 의도하시려고 했던 것 같아요.https://inf.run/7i72V여기에서 답변해주신 것과 피피티의 샤드 번호 현황?이 달라서 조금 혼란스러웠습니다. 링크 답변을 보면 아주 간단한 샤딩 예시였지만, 물리 샤드가 두 개일 때 % 2를 적용하면 1번 샤드(나머지 연산결과 +1)에는 article_Id가 [2, 4, 6, 8]이 들어가고 2번 샤드에는 [1, 3, 5, 7]이 들어갈 테죠.논리 샤드 기준으로는1번 논리샤드 = [4, 8]2번 논리샤드 = [1, 5]3번 논리샤드 = [2, 6]4번 논리샤드= [3, 7] 1번 물리 샤드에는 1, 3번 논리 샤드2번 물리 샤드에는 2, 4번 논리 샤드(링크 답변과 동일한 분포)이게 제가 위의 답변을 강의 자료에 적용해서 이해한 샤딩 현황입니다! 실제 프로덕션에서도 이렇게 샤딩하는지는 모르겠지만 교육 목적 상 간단한 해싱이었어도 제대로 이해하고 넘어가고 싶었습니다.PPT만 보고는 나머지 연산이 어떻게 사용된 건지 이해가 안 됐는데 답변 보고 이해가 돼서 확인 차 질문드렸습니다.추가적으로 클라이언트는 논리 샤드만 알고 있다고 하셨는데 그럼 물리 샤드 번호는 물리적으로 나뉜 샤드를 구분하는 데만 사용하고 비즈니스 로직에서는 사용되는 일이 없을까요?감사합니다.

결제와 주문, 배송과 주문 관계까 1대1인데 결제, 배송 쪽 관계 표시가 선택적1로 되어 있는데 잘못된거 아닌가요'?

사이드프로젝트로 백엔드 시스템을 개발할때 어떤 순서로 해야되나요? 데이터베이스 설계를 먼저 한 뒤에 코드작성을 시작해야되나요? 그리고 만약 개발과정에서 처음 설계한 데이터베이스 규칙에 위반되는 코드가 나온다면 어떻게 해야하나요?

안녕하세요 영한님. 강의를 들으면서 파편화된 정보를 정리하고 있어 너무 즐겁게 강의를 듣고 있습니다.  그런데 AI 퀴즈를 풀던 중 해당 퀴즈에서 뭔가 의아함을 느껴 질문드립니다.   물론 A를 토대로, 외래 키 컬럼에 NULL을 허용함으로써 선택적 참여를 구현할 수 있다는 것까지는 이해할 수 있겠습니다.   다만 [별도 참여 테이블 생성]이 위에 말씀 주신 member를 생성하는 것이라면 B가 더 적합한 선택지라는 생각이 듭니다.  혹시 [별도 참여 테이블 생성]이라는 선택지는 team / member 외의 테이블을 하나 더 만드는 것을 의미했던 걸까요? 비롯해서 해설에 있는 [맞을까요?]라는 질문이 적절하지 않게 느껴지는데요.  인프런으로 문의드릴까 하다가, 문제에 대한 질문을 드리는 것은 이쪽이 맞을 것 같아서 QnA로 질문드립니다!

게시글 조회 기능을 확장하려고 할 때 댓글을 조회하는 방향에 대해 고민이 있어서 질문 남깁니다.게시글 하나를 보는 페이지로 사용자가 이동해서, 게시글의 내용과 댓글들까지 이동한 페이지에서 그려야 할 때 게시글 정보와 해당 게시글의 모든 댓글을 가져오는 기능을 신규로 추가하려고 합니다. 해당 기능의 구현에 대해 2 가지 방향을 고민해봤습니다.게시글처럼 댓글까지 캐싱하는 방법Hot data 로 캐싱된 게시글들의 댓글들을 캐싱하는 것을 고민했을 때, 댓글은 게시글보다 훨씬 많은 양이기 때문에 캐싱에 대한 비용이 너무 커지는 것에 부담이 생기는 문제가 있다고 생각합니다.댓글에 대한 조회는 매번 댓글 서비스에서 조회하는 방법실시간으로 게시물의 댓글을 계속 조회한다면, 조회 서비스에 읽기 부하가 크게 걸릴 것으로 생각합니다. 두 방식 다 장단점이 있다고 생각하는데, 강사님께선 어떤 방식으로 게시글 + 댓글 조회 기능을 구현하실지 의견이 궁금합니다!

프론트엔드 개발자와 함께 작업을 하게 된다면 용어 사전같은 프로젝드 관련 파일들을 공유 하는지 궁금 합니다.

안녕하세요 영한님!!강의 복습에 있어 설계 강의는 어떻게 강의 복습을 해야하는지 너무 뜬구름 잡는 기분이라 조언을 얻고자 합니다.설계라는 게 아직은 멀리 있는 과정이라 생각이 들어서 그런지 더욱 어려운것 같습니다조언 부탁드려요!

해당 강의를 수강하기 전에 사전 학습으로 준비하면 좋은 내용들(MySQL, Redis, Kafka, 시스템 설계 등)에 대해 추천해주실 만한 책이나 강의가 있을까요?저에게는 이 강의가 다소 어렵게 느껴져서, 관련 내용을 따로 공부한 후 다시 수강하고 싶습니다.혹시 강의 내용과 연관되어 쿠케님께서 좋다고 느끼셨던 자료나 도움이 되었던 책, 강의 등이 있다면 공유 부탁드립니다!

이전 강의를 듣지않고 수강하고 있습니다.이전 강의에 대한 정보가 없어서 간혹 영상에 보이는대로 따라서 메우고 있는데, response 함수에 대한 정보는 아직 화면에 나온 적이 없는거 같아서요. 어차피 JSON으로 응답이 오는거 같아서 c.JSON 을 통해 처리했습니다.아직 완강하기 전이라 후반부에 나오는지는 잘 모르겠지만 뼈대가 되는 코드에 대한 정보가 조금 더 있었으면 좋겠습니다. 강의 잘 듣고 있습니다. 감사합니다.

A, B, C 이렇게 세 개의 테이블이 있는데요,A → B, B → C, C → A 이렇게 서로 참조하고 있는 구조입니다.문제는 이렇게 되어 있으니까,예를 들어 B를 지우려면 A가 걸리고,A를 지우려면 또 C가 걸리고,C를 지우려면 다시 A가 걸려서결국 서로 물려서 삭제가 안 되는 상황이 생깁니다.예를 들면A = 학생(Student) → 어떤 수업(B) 에 참여하고,B = 수업(Class) → 그 수업은 교사(C) 가 담당하며,C = 교사(Teacher) → 교사는 자신이 가르치는 학생(A) 들의 리스트를 참조(관리용).이 예시는 정확한 상황은 아니고 제가 생각해서 만들어낸 예시입니다 조금 안맞을수 있는데 만약에 이런 경우에 보통 어떻게 처리해야하나요?