이렇게 3단분리를 할때 처음부터 코드를 작성할때 이렇게 3가지 역할을 분리해서 각각 구현해야지! 라고 다 미리 설정해두고 코드를 짜는건가요 아니면 controller 에 일단 다 구현해놓고 그다음 분리해서 구현하는건가요?? 전자면 미리 생각하게 많아 뭔가 복잡해보여서요 ㅜ

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]영한 강사님이 추천하시는 db설계책이 있을까요?

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요?섹션3[2주차]설득력을 높이는 수치화 기술11강 2-4 프로젝트 기본 설정하기 & 로컬 모니터링 인프라 설정  2. 어려움을 겪는 부분어느 부분에서 막히셨나요? 14:08분 build 시 test 시 런칭 시점에 테스트를 모두 통과하도록 변경했다고 하는데, 실제 build시에 테스트 task 수행 시 DB에 연결할 수 없는 오류가 발생합니다docker compose up 후 bootRun시 localhost:8080/api/chapter2/boards시 응답 값은 제대로 나옵니다  3. 시도해보신 내용문제 해결을 위해 어떤 시도를 해보셨나요?에러가 발생했다면 어떤 에러인가요?EventJoinWithExternalApiUpdateFacadeTest > 외부 API 호출과 DB 업데이트 불일치 테스트 FAILED java.lang.AssertionError at EventJoinWithExternalApiUpdateFacadeTest.java:103SimpleEventListenerTest > 현재 코드 구조에서 @TransactionalEventListener는 작동하지 않는다 FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:143 Caused by: org.springframework.beans.factory.BeanCreationException at AbstractAutowireCapableBeanFactory.java:1770 Caused by: jakarta.persistence.PersistenceException at AbstractEntityManagerFactoryBean.java:421 Caused by: org.hibernate.exception.JDBCConnectionException at SQLExceptionTypeDelegate.java:49 Caused by: java.sql.SQLNonTransientConnectionException at SQLError.java:111 Caused by: org.springframework.beans.factory.BeanCreationException at AbstractAutowireCapableBeanFactory.java:1770 Caused by: jakarta.persistence.PersistenceException at AbstractEntityManagerFactoryBean.java:421 Caused by: org.hibernate.exception.JDBCConnectionException at SQLExceptionTypeDelegate.java:49 Caused by: java.sql.SQLNonTransientConnectionException at SQLError.java:111SimpleEventListenerTest > @TransactionalEventListener는 활성 트랜잭션이 필요하다 FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:143 Caused by: org.springframework.beans.factory.BeanCreationException at AbstractAutowireCapableBeanFactory.java:1770 Caused by: jakarta.persistence.PersistenceException at AbstractEntityManagerFactoryBean.java:421 Caused by: org.hibernate.exception.JDBCConnectionException at SQLExceptionTypeDelegate.java:49 Caused by: java.sql.SQLNonTransientConnectionException at SQLError.java:111 Caused by: org.springframework.beans.factory.BeanCreationException at AbstractAutowireCapableBeanFactory.java:1770 Caused by: jakarta.persistence.PersistenceException at AbstractEntityManagerFactoryBean.java:421 Caused by: org.hibernate.exception.JDBCConnectionException at SQLExceptionTypeDelegate.java:49 Caused by: java.sql.SQLNonTransientConnectionException at SQLError.java:111SimpleEventListenerTest > @EventListener는 트랜잭션이 없어도 정상 동작한다 FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:143 Caused by: org.springframework.beans.factory.BeanCreationException at AbstractAutowireCapableBeanFactory.java:1770 Caused by: jakarta.persistence.PersistenceException at AbstractEntityManagerFactoryBean.java:421 Caused by: org.hibernate.exception.JDBCConnectionException at SQLExceptionTypeDelegate.java:49 Caused by: java.sql.SQLNonTransientConnectionException at SQLError.java:111 Caused by: org.springframework.beans.factory.BeanCreationException at AbstractAutowireCapableBeanFactory.java:1770 Caused by: jakarta.persistence.PersistenceException at AbstractEntityManagerFactoryBean.java:421 Caused by: org.hibernate.exception.JDBCConnectionException at SQLExceptionTypeDelegate.java:49 Caused by: java.sql.SQLNonTransientConnectionException at SQLError.java:111 현재 작성하신 코드를 공유해주세요 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!

휘발성이 강한 access_token 을 redis 에 저장하지 않고, 굳이 mysql 에 저장하는 이유가 있을까요??

SELECT city FROM station WHERE city LIKE 'a%' OR LIKE 'e%' OR LIKE 'i%' OR LIKE 'o%' OR LIKE 'u%'

@Transactional public void returnBook(BookReturnRequest request) { User user = userRepository.findByName(request.getUserName()) .orElseThrow(IllegalArgumentException::new); user.returnBook(request.getBookName()); }위 코드의 BookService 에서 책을 반납할때 userLoanHistory 중 user명과 책 이름이 같은것을 가져와서 userLoanHistory 에서 리턴하는데 문제는 한 사람이 이미 같은 책을 빌렸고 반납한 기록이 있다면 중복으로 잡힙니다.public void returnBook(String bookName) { UserLoanHistory targetHistory = this.userLoanHistories.stream() .filter(history -> history.getBookName().equals(bookName)) .findFirst() .orElseThrow(IllegalArgumentException::new); targetHistory.doReturn(); }위의 User 엔티티에서 혹시 userLoanHistory 값이 여러개 나올때 혹시 .findFirst() 를 통해 그 중 가장 위즉, 여기선 가장 최근에 대출한 책의 기록인 userLoanHistory 를 가져와서 doReturn()을 진행하는 형태가 맞습니까?

인덱스가 아래와 같을때idx_orders_user_status(user_id, status, created_at)아래 쿼리문이 왜 문제인지 궁금합니다.select * from orders where 1=1 and status = 'pending' and user_id = 123강의 내용(11분 30초)에서는 인덱스의 컬럼 순서와 조건문(where)의 컬럼 순서가 틀려 효율적이지 못하다고 설명해 주시는 거 같습니다.하지만 이는 옵티마이저에 의해 where절의 컬럼 순서를 재계획 하는 걸로 알 고 있습니다.강의의 의도는 left prefix index rule 때문에 인덱스 순서를 조심해야 한다는 내용인 거 같은데... 혹시 꼭 순서를 지켜야 하는 이유가 있을까요??(첫 번째 인덱스 미사용, 중간 컬럼 미사용, 커버링 인덱스 등의 특정 상황 제외)

안녕하세요. 항상 영상 잘 시청하고 있습니다.이번에 강의를 시청과 실무에서 업무를 하면서 궁금한 사항이 있어서 질문을 작성합니다.실무에서 인덱스 및 DB에 대해서 최근에 고민이 있습니다. 하나의 테이블에 어쩔 수 없이 컬럼이 많아지는 경우 인덱스가 많아지는 경우가 있어 고민이 됩니다. 물론 상황마다 다르겠지만 강사님의 의견이 궁금하여 질문을 드립니다. 질문인덱스 : 조회의 다양한 경우가 있어서 인덱스가 과도하게 많아지는 경우가 있습니다.ex) 복합 인덱스 (A,B,C)가 있다고 가정하면 선행 인덱스가 포함되지 않는 경우에 그냥 인덱스를 추가를 하시는지 궁금합니다. 간단하게 강의에서 post를 기준으로 (title, content)의 인덱스에서 나중에 content만 필터를 해야 되는 경우 ( 실제로 content에 인덱스는 적절하지 않다고 생각하지만 예시 ) 1-1. 만약에 추가를 하게 된다면 하나의 Table에 최대 인덱스 개수는 몇개로 지정을 하시는지 궁금합니다. 너무 많아지게 되면 Write작업에 대해서 부화를 가지기 때문에 측정을 하시는 기준점이 있는지 궁금합니다. ( 상황마다 다르겠지만 일반적으로 생각하시는 기준 )  MySQL에서 집계에 대한 아키텍처하나의 재고를 row로 표현하는 테이블이 있다고 가정하면 특정 상품의 재고를 구하기 위해서 count를 사용을 해야됩니다. (하나의 row는 상품 1개)캐싱을 처리하면 데이터의 정합성에 문제가 생기고 매번 쿼리를 실행하면 성능 및 DB에 부화가 발생합니다.이것을 개선하기 위해서 만약에 집계 테이블을 만들어 Redis, Kafka에서 이벤트가 발생하면 집계 테이블에 개수를 수정하는 방식으로 실무에서 많이 사용되는지 궁금합니다.만약에 많이 사용이 된다면 주의사항이 어떤게 있을까요??  

영상의 10분 38초 기준으로 Postman을 사용했을 때 결과가 다르게 나옵니다.처음에는 "Error: connect ECONNREFUSED IPv4:8080" 라는 에러가 반복적으로 발생했습니다.혹시 제가 뭔가 놓쳤나 싶어 인스턴스를 새로 만들어 시도해보고, 이전 섹션부터 다시 꼼꼼히 확인도 했습니다.또, 중간에 인스턴스가 끊기는 문제가 있어 micro에서 small로 업그레이드까지 해보았는데요.여러 방법을 시도했음에도 불구하고 지금은 500 Internal Server Error만 발생하고 있어 해결책이 떠오르지 않아 질문을 남깁니다.

강사님께서 API 가 프로그램 간 정해진 약속을 해서 정해진 기능을 수행하는 것이라고 말씀해주셨는데 그럼 프로토콜과 API 가 같은 건가요??

안녕하세요, 영한님. 강의록에 사소한 오타가 있어 제보합니다. [오타 정보]위치: 12. 저장 프로시저, 함수, 트리거.pdf - p.5 맨 위의 '프로시저 호출(CALL)' 부분내용:변경 전: 이제 user_id가 2번인 '네이트' 고객의 주소를 '경기도 성남시'로 변경하는 프로시저를 호출해 보자.변경 후: 이제 user_id가 2번인 '네이트' 고객의 주소를 '경기도 성남시2'로 변경하는 프로시저를 호출해 보자.

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요?4-10 입니다 여기까지 이해하신 내용은 무엇인가요?네임드 락은 분산환경에서 유리하다. 2. 어려움을 겪는 부분어떤 개념이 헷갈리시나요?네임드 락이 분산 환경에서 유리하다 하신 내용에서, 데이터베이스 레벨의 락 제공이기에 유리하다고 이해하였습니다.하지만 비관적락, 낙관적 락 둘 다, db 단 에서 락을 획득하거나 버전 관리를 통해 이루어 진다고 이해하고 있어서 그렇다면 분산 환경에서 유리하다는 것이 네임드 락만의 장점이 아닌것 같다고 생각이 들었습니다.스프링에서 비관적락, 낙관적 락을 jpa 를 활용하여 걸게 된다면, dbever 에서 테스트 해본 것 처럼 db 단에서 처리되어 락을 수행하게 되는 내용이 정확히 맞는지 궁금합니다.만약 맞다면 네임드 락이 분산 환경에서 유리하다는 것이 db 단에서 처리되고, 그 방식 자체가 분산환경에 유리한 내용을 가지고 있는건지 궁금합니다.

1. 현재 학습 진도몇 챕터/몇 강을 수강 중이신가요? 여기까지 이해하신 내용은 무엇인가요? 2. 어려움을 겪는 부분어느 부분에서 막히셨나요?코드의 어떤 로직이 이해가 안 되시나요?어떤 개념이 헷갈리시나요? 3. 시도해보신 내용문제 해결을 위해 어떤 시도를 해보셨나요?에러가 발생했다면 어떤 에러인가요?현재 작성하신 코드를 공유해주세요 이렇게 구체적으로 알려주시면, 더 정확하고 도움이 되는 답변을 드릴 수 있습니다!  안녕하세요 강의 잘 보고 있습니다.인덱스 타입은 인덱스만 조회하는 경우에는 단순히 논 클러스터 인덱스 안에 있는 칼럼 값들만 조회하기만 하면된다. 라고 말씀을 하셨습니다.근데 제가 클러스터 인덱스/논클러스터 인덱스/ 커버링 인덱스에 대한 개념을 아래와 같이 이해를 했습니다.클러스터 인덱스 - PK를 키로 리프 노드에 모든 데이터가 저장돼 있는 구조 논클러스터 인덱스 - 세컨더리 인덱스를 키로 가지고, 리프 노드에는 “해당 세컨더리 인덱스의 PK를 데이터로 가지고 있음”.커버링 인덱스 - 세컨더리 인덱스를 키로 가지고 있으며, 리프 노드에 “ 해당 세컨더리 인덱스의 PK와 실제 데이터를 가지고 있음”   그래서 위 사진과 같이 설명을 하셨을 때, 잘 이해가 되지 않은 부분이 price만 보는 경우에는 단순히 논 클러스터 인덱스 안에 있는 칼럼 값들만 조회하기만 하면 된다.라는 말씀이 잘 이해가 되지 않습니다.논 클러스터 인덱스의 경우에는 저는 아래와 같이 이해를 했습니다. 1.세컨더리 인덱스가 key이고, 리프 노드에 데이터로 PK를 가지고 있음2.그래서 세컨더리 인덱데스로 원하는 데이터를 직접 찾기 위해서는 리프 노드에 있는 PK를 이용해서 직접 클러스터 인덱스로 접근해서 데이틀 조회해야됨” 그래서 제가 이해한 부분 중에 틀린 부분이 있는걸까요?아니면 제가 이해한게 맞다면 “ price만 보는 경우에는 단순히 논 클러스터 인덱스 안에 있는 칼럼 값들만 조회하기만 하면 된다”라는 말씀이 잘 이해가 되질 않습니다.감사합니다.

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]안녕하세요! 선생님 강의 잘 듣고 있습니다. 23:16초에서 "실무에서 이것이 왜 중요할까?" 부분이 잘 이해가 안가서 질문 드립니다.  제가 이해한 바로는 FROM users JOIN orders 와FROM orders JOIN users 의 차이는 안에서 복제를 해서 전체 행의 수가 늘어나는지, 자식 테이블의 행 개수가 그대로 유지인지 이 차이이고,결과물은 같다고 생각합니다. (inner join은 교집합이니깐) 그런데 지금 실무에서 이것이 왜 중요할까? 부분에서 <<집계함수인 COUNT(u.user_id)를 실행하면 어떻게 될까? 주문을 여러번 한 고객이 중복 계산되므로 전체 주문 수인 7이 나온다>>고 하셨는데 기준 테이블을 부모로 잡든 자식으로 잡든 결과는 똑같지 않나요?  제가 저 구문의 의도를 잘 파악하지못하여 질문 드립니다.   

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용] 강사님의 예제처럼 GROUP BY 와 ORDER BY 를 사용했습니다. 이때, 카테고리별 구매금액 정렬이 함수와 백틱을 사용했을 때 경우가 다르게 동작하는데 그 이유가 궁금합니다. 세종대왕 케이스를 확인해주시면 감사하겠습니다. 함수를 직접 사용하였을 때 백틱을 사용하였을 때 

교재 26~27 페이지SELECT customre_id FROM orders 실행 결과에 대해 1, 1, 2, 2, 2로 제공실제로는 1, 1, 2, 2, 3강의에서는 정상적으로 나와있습니다!

문제2 : 쇼핑몰 매출 현황 파악하기 에서 '평균 주문 금액'을 구하는것에 질문이 있습니다.  제가 생각한 답은 SELECT SUM(price*quantity) , SUM(price*quantity)/COUNT(*), MAX(price), MIN(price)FROM order_stat;이것인데,  강의에서는 AVG를 이용해서 하셨는데, 혹시 실무에서는 어떻게 구할까요?  

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)[질문 내용]46. GROUP BY - 그룹으로 묶기 강의 중 그룹으로 묶은 뒤 집계 함수를 사용한 컬럼을 기준으로 정렬하는 내용에 질문이 있습니다.ORDER BY에 총 구매 금액 이라는 alias로 지정한 컬럼명을 사용해도 되고, sum(price * quantity)로 SELECT 절에서 사용한 집계함수를 다시 사용해서 정렬해도 된다고 설명해주셨습니다.만약 집계함수를 사용했을 땐 계산을 또 해야하고, 컬럼명을 사용했을 땐 컬럼을 참조만 한다면 성능에 차이가 생기지 않을까라는 생각이 들었습니다.ORDER BY 절에 집계함수를 사용하는 것과 컬럼명을 사용하는 것의 동작 원리가 같은지, 성능상의 차이가 있는지 궁금합니다.

현재 강의를 시작하는 단계입니다. 뒷 강의에서 설명이 나올지 모르겠지만 현재 프로시저만 보았을 때 CALL 명령에서 GenerateUsers만 진행하고 Account는 부르지 않고있는데 의도하신걸까요?

안녕하세요 스승님!질문드립니다! 데이터 정합성을 위한 확인 절차는 front, back, DB에서 3중으로 처리하는게 좋은가요? 아니면 애플리케이션 레이어에서 처리하는게 좋을까요? (3중으로 하면 처리가 빠르고 정확할 수 있다는 장점이 있지만 처리 조건이 변경되는 경우 3군데에서 모두 변경이 있어야한다는 점이 꽤 번거로울 것 같습니다...)이후 설계에서 다뤄주시겠지만, 1:1 관계의 테이블로 연결된 두 테이블에서 FK에 UNIQUE 제약을 거는게 일반적인지도 궁금합니다.매번 덕분에 성장하고있슴다!감사합니다!