어떻게 보면 이 수업과는 조금은 먼 이야기일수도 있는데 실제 프로젝트에서 JPA를 다루다보니 엔티티 선언시에 시간 타입 정의를 어떻게 처리해야 할지가 항상 고민이 되더라구요. 현재 프로젝트에서는 Entity 정의시에는 Instant를 사용을 하는데, 혹시 추천하시는 방법이 있을까요??

풀 외부 조인을 잘 사용하지는 않지만 가끔 사용하실 때가 있다고 했는데 어떨 때 사용하셨는지 궁금합니다.

실무에서도 외래 키(Foreign Key)를 쓸수 있는 상황이지만특별히 쓰지않고 처리하는 경우가 있을까요? 예를 들어 시스템 초기에 보다 유연한 설계를 위해?데이터 보전을 위해? 아니면 쓸수 있으면 최대한 쓰는게 맞을까요?

 안녕하세요.섹션 8에서 장바구니에 주문을 생성할 때 같은 상품이 중복으로 생성되게 하지 않게 제약 조건을 걸었는데실무에서는 쿼리에서 제약 조건을 거는 지아니면 애플리케이션에서- 없을 때 추가- 있을 경우 수량 증가와 같이 아니면 비즈니스 로직에서만 처리 하는 지어떤 케이스나 어느 비율로 적용하는 사례가 궁금합니다. 

aop의 단점을 보완하기 위해 advice 패턴을 사용하셨는데, 매번 코드에 advice가 들어가는게 좀 번거로울 수도 있을거 같다는 생각이 들어서 질문드립니다..! aop의 단점을 극복하기 위해 사용한거지만,, 혹시 Advice를 aop처럼 분리시켜서 적용시키는 방법이 따로 또 있을까요

database mysql을 사용하다가 질문드립니다create index idx_items_stock_quantity on items(stock_quantity);이렇게 인덱스를 생성하고 order by를 다음과 같이 stock_quantity를 기준으로 한다면,explain select * from items order by stock_quantity;이렇게 실행계획을 보면 이 쿼리의 type이 적어도 ALL로 나오진 않을거라고 생각했습니다. 그냥 인덱스를 stock_quantity를 기준으로 생성하면 알아서 정렬이 되어 있을 거니까요. 그런데, 실제로 확인해보니까 type이 ALL로 나옵니다. 왜 그런걸까요?(by Claude Sonnet 4.5) select *의 경우 1. stock_quantity 인덱스를 활용한 랜덤 I/O를 하는 경우2. 테이블을 순차적으로 쭉 읽는 순차 I/O를 하는 경우이 두 경우 중 옵티마이저가 2번째 방법을 활용해서 그렇다고 합니다. 그냥 이렇게 알고 있으면 될까요?

비전공자이고 백엔드로 하고 싶은데,AI가 발전한 현재 시점에서 어떻게 공부를 해야 할지 조언을 구하고 싶습니다.

강의중 로직이 복잡해지면, 테이블에서 관련 컬럼들을 다시 분리해야 하는날이 올 수 있다고하셨는데컬럼을 다시 분리해야 할 때, 실무에서는 어떤 절차로 나누는지와 생길 수 있는 문제점에는 어떤 게 있나요?

외래키 제약조건을 통해 보다 정확한 데이터 무결성을 보장할 수 있을 것 같습니다.하지만 실무에서는 외래키로 인해서 데드락이 발생하는 케이스가 있을 것 같습니다. 또한 외래키로 인해 운영 상에서 제약조건을 잠시 해제해야된다던가 하는 경우가 발생할 것 같은데, 실무에서도 외래키를 주로 걸고 운영할까요??

기존에는 @Transactional만으로 데이터 일관성이 보장된다고 생각했습니다. 하지만 강의를 들으며 동시에 재고를 조회·갱신하는 상황에서 격리성이 보장되지 않는 문제가 발생할 수 있다는 점을 뒤늦게 인식했습니다.  이런 흐름을 이력서에서 “단순 구현 → 시스템 안정성 중심의 설계로 성장한 과정”으로 기술적 사고 확장으로 어필해도 괜찮을까요? 아니면 너무 이론적으로 보일까요?(항상 서비스 내 로직만 고려해서 롤백 여부로 트랜잭션을 생각했는데, 큰일이네요ㅜㅜ )

두개 이상의 테이블을 조인 할 때 서로 다른 테이블에 있는 데이터로 ORDER BY 정렬을 하게 되는 경우가 있을 것 같은데 이런 경우에는 인덱스를 어떻게 생성해야 하는지 궁금합니다

학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]안녕하세요! 강의를 듣다보니 db 파일들은 히스토리가 어떻게 관리되고 어떤 단위로 파일을 나누는지 궁금합니다!

안녕하세요, 김영한 지식공유자님.현재 자바개발 2년차 개발자입니다.자바와 DB공부를 병행하고 있습니다.자바와 스프링 공부 vs SQLP 공부로 고민을 한다면,자바와 스프링 공부보다 SQLP를 따기위한 노력에 가중치 높이는게 좋은 선택일까요?

안녕하세요. 강사님의 강의를 2회독하며 궁금한 것들이 어느정도 정리가 되어 질문 드립니다.제가 SI에 있어서 그런건지 혹은 프로젝트? 운이 없어서인지 차세대를 하더라도 돌이켜보면 경험했던 실무에서는 늘 자연키를 PK로 사용 했었습니다. 그러다보니 UPDATE, DELETE등 데이터를 핸들링 할 때에도 늘 PK(자연키)를 전부 들고다니며 사용 했었는데대리키를 PK로 사용할 경우에는 PK도 항상 같이 다른 데이터 들과 함께 객체등에 담는지.. 혹은 데이터를 갱신 할 때에만 자연키들로 따로 pk를 조회 한 후 사용하는지 아니면 unique 조건이 걸린 자연키들로만 갱신을 하는지 궁금해서요 ㅜㅜ

mysql 커뮤니티버전과 사용버전의 차이가 크게 없는건가요?

안녕하세요, 강의를 통해 대규모 시스템 설계에 대한 다양하고 실무적인 방법을 배우게 되어 감사히 수강하고 있습니다!수강중 Transactional Outbox 테이블 관련하여 궁금한 부분이 있어 질문드립니다.실무에서는 보통 "Outbox 테이블에 Insert -> kafka send 후 Outbox 상태 Update" 하는 방식으로 쓰일까요? 강의에서는 간단히 Delete로 구현한다고 말씀주셔서 질문드려봅니다!Update 하는 방식도 자주 쓰인다면 Outbox 테이블은 파티셔닝(p20251001 와 같이)하여 관리하고 주기적으로 삭제하는 방식일지도 궁금하여 질문드립니다!  

=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 아니오2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)예[질문 내용]MySQL은 학습용으로는 많이 사용하는데, 실무에서도 MySQL을 쓰는 회사가 있을까요?만약 그렇지 않다면 어떤 이유에서 쓰지 않는지 궁금합니다.

안녕하세요 강사님!카프카를 사용하면서 궁금한 점이 있어서요~ 예를 들어 주문 시스템을 구현한다고 하면요.주문에 대해 상태가 계속 바뀌어 해당 이벤트를 받을 수 있도록 카프카를 붙이려고해요.consumer가 동일한 주문 id에 대해 상태 업데이트를 해야 하니, producer가 순서 보장되도록 카프카 key도 동일하게 셋팅하면 consumer는 순서대로 status를 제대로 update 하는데요. 만약 producer가 메시지 발행을 비동기적으로 진행하도록 구현했다고 하면,무언가 이슈로 주문 생성 -> 주문 취소 순이 아닌 주문 취소 -> 주문 생성 순으로 발행되었다면consumer 입장에서 메시지 순서가 제대로 들어왔음을 어떻게 인지할 수 있을까요..? 이런 상황은 발생하지 않을까요..? ㅎㅎ

안녕하세요!현대적인 설계에서는 대부분 자연 키가 아닌 대리 키를 기본 키로 사용하는 것이 권장된다고 하셨는데요.그렇다면 혹시 자연 키를 기본 키로 사용해도 괜찮은 예외적인 상황이 있을까요?예를 들어, 변경 가능성이 거의 없는 코드성 데이터나 표준화된 식별자(예: ISO 코드, 통화 코드 등) 같은 경우에도 무조건 대리 키를 추가하는 것이 좋은지, 아니면 자연 키를 PK로 두어도 실무적으로 문제가 없는 기준이 있는지 궁금합니다. 감사합니다 ☺︎

안녕하세요, 강사님.데이터를 효율적으로 JOIN 하여 어떻게 가져올지에 대한 방안에 대해 고민하던 중, 궁금한 점이 있어 질문을 드립니다. 강사님의 강의를 들으며 JOIN 시 결과 행수 차이에 대해 아래와 같이 이해했습니다.부모 테이블에서 자식 테이블로 JOIN할 경우→ 결과 행수가 부모 기준으로 유지된다.자식 테이블에서 부모 테이블로 JOIN할 경우→ 결과 행수가 자식 행수에 따라 크게 늘어날 수 있다.그렇다면 아래와 같은 상황에서 어떻게 처리하는 게 효율적일지 궁금합니다. 강의 상세 페이지처럼 여러 유형의 데이터를 한 번에 가져와야 하는 경우> 예시) 강의 정보, 강사 정보, 강의 평점, 강의 리뷰 등부모 테이블(강의)에서 자식 테이블(강사 정보, 강의 평점)로 JOIN할 때, 결과 행수가 부모 테이블 기준으로 유지되거나 크게 늘어나지 않는 상황에서는 한 번의 쿼리로 모든 데이터를 조회하는 것이 좋은 방법일까요 ?반대로, 강의 리뷰처럼 자식 테이블의 데이터가 많아져서 결과 행수가 급격히 늘어날 경우에는 리뷰 데이터만 별도의 쿼리 또는 API로 분리해서 조회하는 것이 더 바람직할지 궁금합니다.결국, 관계 방향과 데이터 양에 따라 결과 행수가 크게 늘어나지 않는 JOIN까지만 한 번에 처리하고,행수가 많아지는 데이터(예: 리뷰)는 별도로 쿼리하거나 API를 분리하는 전략이 좋을지, 그리고 쿼리/API 분리 기준을 어떻게 결정하는게 좋을지 설명해주시면 큰 도움이 될 것 같습니다.감사합니다.