학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용]안녕하세요, 강의 잘 듣고있습니다.최근 파티셔닝이란 개념에대해 알게되었는데, 강의 내용엔 파티셔닝이 포함되어있지 않는 것 같아서 실무에서는 파티셔닝은 잘 사용하지 않는지 인덱스와는 어떤 차이가 있는 지, 파티셔닝을 실무에서 사용하지 않는다면 어떤 이유 때문인지 궁금합니다. 제가 검색 등으로 정보를 취득해봤을 땐, 주로 인덱스보다 더 큰 규모의 데이터를 다룰 때 파티셔닝을 쓰고 인덱스+파티셔닝을 함께 쓰면 더 좋은 결과를 얻을 수 있다는 것 같은데 실무에서도 해당 내용이 맞는 지도 궁금합니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요. mysql을 다운 하라는 곳에 들어가 제대로 다운 했는데 화면이 강의에서 보는 것과 달라 맨붕이 옵니다. 다시 다운을 해도 똑같은 화면입니다 버전도 용량이 큰거도 다운했습니다. 어떻게 해야할까요..

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용] join 문제와 풀이2에서 문제 1번에 대한 질문입니다.풀이는 아래 쿼리 중 1번의 형태로 해주셨는데 저는 풀이 보기 전 혼자 풀었을 때 2번의 형태로 작성을 했는데...일단 동작은 둘 다 같은데 유지보수적인 면이라던지 의미적인 면이라던지 더 좋은 형태가 있는 지, 둘의 차이가 있는 지 궁금하여 질문 드립니다. 1번 쿼리SELECT m.employee_id, mname, m.manager_id, enameFROM employees eJOIN employees m ON e.employee_id = m.manager_idWHERE m.manager_id = 42번 쿼리SELECT e.employee_id, ename, e.manager_id, mnameFROM employees eJOIN employees m ON e.manager_id = m.employee_idWHERE e.manager_id = 4

실무에서도 복수 항목에 대해서 원자성을 고려해 테이블을 분리하는지 궁금합니다. 예를 들어, 카드 정보라는 테이블이 있을 때, 혜택이라는 컬럼에는 '캐시백', '쿠폰 할인' 이런 식으로 복수의 데이터가 들어가게 되는데, 그럼 따로 카드 혜택이라는 하위 테이블을 만들어서 관리하나요? 이런 복수 항목이 늘어날 때마다 테이블을 하나씩 만들어야 하는지... 테이블 구조가 복잡해지는 느낌이 들어 질문드립니다.

[4페이지 - 예시 2]하나는 "~", 다른 하나는 "AND"인 부분 뭔가 어색?한 거 같습니다.

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요? 여기까지 이해하신 내용은 무엇인가요? 2. 어려움을 겪는 부분어느 부분에서 막히셨나요?코드의 어떤 로직이 이해가 안 되시나요?어떤 개념이 헷갈리시나요? 3. 시도해보신 내용문제 해결을 위해 어떤 시도를 해보셨나요?에러가 발생했다면 어떤 에러인가요?현재 작성하신 코드를 공유해주세요  안녕하세요 강의 잘 보고 있습니다. 저는 강의를 보고 아래와 같이 이해를 했습니다.1.API 별 실행 쿼리 모니터링 구현2.그러면, 모든 api 엔드포인트에 대한 쿼리 min , max값을 알 수 있음. 질문1근데, 그렇게 되면 실제로 서비스에 필요한 코드와 모니터링 코드가 불필요하게 섞이는 거 아닌가요? 왜냐하면, 실제 모니터링이라고 하면 서버를 유지보수할 때, 필요한 데이터를 실시간으로 받아와서 시각화한다는 것으로 이해를 했습니다. 그런데 "API 별 실행 쿼리 모니터링 구현"은 서버의 유지보수에 필요한 모니터링 기능이 아니라,  1번만 딱 실행되면 되는데 이 부분이 왜 모니터링 구현으로 분류가 되는지 잘 모르겠습니다!  질문2API 별 실행 쿼리 모니터링 구현 부분에서, 실무에서도 "API 별 실행 쿼리 모니터링을 구현"해서 사용하는게 맞나요? 잘은 모르겠지만, 쿼리 분석이나 다른 방법이 있을 것 같은데 왜 이 부분이 서비스 코드 내에 포함을 시키면서까지 모니터링의 영역으로 분류가 되는지 잘 모르겠습니다 ! 질문3 만약에 실무에서는 해당 방법을 잘 사용하지 않는다면 API 별 실행 쿼리 횟수를 보통 어떤 식으로 측정을 하는건가요??? 감사합니다 !    이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!

역할 및 발생 시점에 따른 엔티티 분류를 설명하는 파트에서 궁금한 점이 있습니다. 지난 강의까지 주문 엔티티는 사건 발생의 결과물(즉, 주문 이력)이 기록되는 엔티티라고 이해했었는데요."엔티티 분류1" 강의에서는 기본, 중심, 행위 엔티티로 나눠서 생각해볼 수 있다고 했습니다. 그때 중심 엔티티에서도 예시가 주문으로 나와있고, 행위 엔티티에서도 주문 이력으로 나와 있는데, 이 두 개가 다른 경우인가요? 중심 엔티티의 주문과 행위 엔티티의 차이가 무엇인가요? 감사합니다.

강의에서 stock_quantity 칼럼의 제약 조건으로 다음과 같은 구문을 작성하였는데,stock_quantity INT NOT NULL DEFAULT 0해당 구문에서 NOT NULL 제약조건을 두지 않더라도 DEFAULT 0만 작성하여도 충분히 해당 칼럼이 NULL값이 되는 걸 방지할 수 있으리라 생각이 되어서요. NOT NULL 제약조건을 반드시 작성해야하는 걸까요? 아니면 개발자의 코드 작성 의도를 더 명확히 하고자 작성하는 걸까요?

학습 관련 질문을 최대한 상세히 남겨주세요!고민 과정도 같이 나열해주셔도 좋습니다.먼저 유사한 질문이 있었는지 검색해보세요.인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 혹시 github 자료도 받아볼 수 있나요?

안녕하세요. 사이드 프로젝트를 설계하다 보면 테이블의 키를 어떻게 가져갈지 고민을 많이 하게됩니다. 영한님의 말씀대로 대부분 대체키로 만들지만 숫자 대체키의 경우 1부터 순차적으로 올라가게 대부분 구조가 만들어지게 됩니다. 이게 혹여나 보안에 우려가 있을까 염려됩니다. 안전하게 UUID로 대체키를 주면 강의에서 말씀해 주신것 처럼 성능 부분에서 trade off가 있어서 이 방법도 고민됩니다. 예를 들어서 회원이라면 회원 정보를 조회하는 GET API에 회원ID(숫자 대리키, pk) 를 보내면 해당 유저 정보를 조회하게 되는데 숫자를 임의로 바꿔서 다른 유저 정보를 조회하는 이런 부분에서 혹여나 보안 관점에서 우려가 있지 않을까? 생각을 갖게 됩니다. 그러다 보니 두 가지 방안이 떠오르는데 실무에서 추천해주실 방안이 있는지 궁금합니다. 대체키(숫자)를 사용하되 애플리케이션에서 validation을 확실하게 설정pk는 대체키(숫자, pk)를 하되 db에서 join, 외래키로만 사용하고 외부로 나갈 때는 다른 대체키(UUID, unique)로만 보내는 방식영한님을 기다리며... 답변에 미리 감사드립니다.

문제 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()```