안녕하세요?21번 강의에서 4:04 초에 보면,db.users.find({hobbies: {$in: ["축구", "요리"]}}) -> 이 부분을 sql 로 변형하면 select * from users where hobbies like "%축구%", or hobbies like "%요리%" 와 유사하다고 하셨는데아래 sql 이 더 가까운게 아닌지 문의드립니다. SELECT * FROM users WHERE hobbies IN ('축구', '요리') gemini 한테도 물어보니까 $in 은 정확히 일치하는 항목을 찾는거니까 select .....hobbies in ('축구', '요리') 가 더 비슷할거 같다고 하더라고요.

안녕하세요.histories() 응답에 PointHistory.id가 포함되어 있던데, 이 값을 내려주신 의도가 궁금합니다.FE에서 이 id를 직접 활용해야 하는 지점이 있는지 궁금해서요.예를 들어 포인트 이력 상세 조회나 특정 이력을 식별해야 하는 기능을 염두에 두신 걸까요?현재로서는 다른 필드들만으로도 충분하지 않나 생각되어, id를 포함하신 이유가 궁금합니다!

안녕하세요,현재 studio 3t 설치하려면 첨부한 이미지에서 다운받는게 맞나요? 근데 개인정보 입력시 이메일 부분에 gmail.com 같은 일반 이메일말고 회사 이메일을 적용해야 next 로 넘어갈 수 있는 것 같습니다. 아직 회사에 다니는 상황이아닌데 다르게 다운 받는 방법 있으면 안내부탁드립니다.

뉴스데이터 전처리 - 메타데이터 추출 수업의 실습 파일이 없습니다.그외에도 ipynb을 수행할 수 있는 파일들이 존재하지 않습니다.강의를 수강할 수 있도록 실습 파일 다운로드 받을 수 있는 경로를 부탁드립니다.감사합니다.

@Query( """ SELECT new io.dodn.commerce.storage.db.core.SettlementTargetSummary( settlement.merchantId, settlement.settlementDate, SUM(settlement.targetAmount), COUNT(settlement.id), COUNT(DISTINCT settlement.orderId) ) FROM SettlementTargetEntity settlement WHERE settlement.settlementDate = :settlementDate GROUP BY settlement.merchantId, settlement.settlementDate """, ) fun findSummary(settlementDate: LocalDate): List<SettlementTargetSummary>이부분에서 where절에서 이미 settlementDate를 필터링하고 있는데 group by에서 settlementDate가 필요한 이유가 따로 있을까요? 어차피 parameter로 넘어온 settlementDate만 조회가 되는 로직이라 Group By에서는 필요가 없어보여 질문 남깁니다.

addReview()를 보면 리뷰 저장 이후에 포인트를 지급하는 로직이 함께 들어가 있는데, 제 기준에서는 포인트 지급이 리뷰 작성의 핵심 기능이라기보다 부가 기능처럼 느껴졌습니다.그래서 이런 부분은 서비스 내부에서 직접 호출하기보다 이벤트를 발행하고, 별도의 핸들러에서 처리하는 방식으로 분리해도 괜찮지 않을까 궁금했습니다.(다만 제가 이걸 정말 "부가적인 책임"으로 봐도 되는지 조금 헷갈리기도 합니다.)만약 실무에서는 이런 부가적인 로직을 서비스 메서드 안에 함께 둘지, 아니면 이벤트/이벤트 핸들러 형태로 분리할지를 어떤 기준으로 판단하시는지 궁금합니다.또는 이런 경우 이벤트 외에 다른 방식으로 설계하시는 경우도 있는지 궁금합니다.

안녕하세요~ 강의 중 강사님께서 null을 되도록 허용하지 않는 것으로 보였습니다.공감이 되었는데, CancelEntity.orderItemId 와 같은 곳에 -1 을 설정한 다거나 QnA.answer 에 Answer.EMPTY 를 설정하는 것은 어떤 장점이 있을지 궁금합니다.저는 위와 같은 경우는 해당 필드를 nullable 로 하는 것이 이 필드는 없을 수 있다는 것을 더 명확하게 나타낼 수 있다고 생각했습니다. 좋은 강의 감사합니다!

안녕하세요. sum과 같은 집계함수를 나중에 select 에서 계산한다는 부분이 교재에 조금 헷갈리게 되어있는거 같아서요. 그러니까 sum, count 같은부분은 이미 group by 하고 난다음 select전에 집계함수가 미리 구해진 걸로 ai로 공부하다가 찾아보면서 알게되어서요.. 그렇게 미리 구해진 집계함수가 having이나 select에서 사용되는 거지 select 절에서 계산되는게 아니라고 알게 되었어요. 그거 때문에 성능도 빠른거라고.. 그런데 교재 7. 집계와 그룹핑에 p. 31에 보면 5번 select 절이 실행될때 집계함수 계산이 여기에 이루어진다고 나와있습니다. 수정이 필요한게 아닌가 싶습니다. 아.. 그래서 group by 가 없는 경우와도 헷갈렸었는데 그 경우도 select에서 집계함수가 계산된다기 보다 group by가 없어도 전체 데이터가 하나의 데이터로 implicit grouping으로 select 전에 계산되어지고 select에서는 보여주는 것만 관여하는게 되어서 흐름이 맞춰지더라구요... 개인적으로..  공식문서에 https://dev.mysql.com/doc/refman/8.0/en/aggregate-functions.html"This section describes aggregate functions that operate on sets of values"

자바에서 클래스 필드 타입을 참조타입과 원시타입의 차이를 공부하던 중에둘의 차이가 null 값이 필요하냐 필요하지 않냐로 배웠습니다..그런데 엔티티 pk의 경우에는jpa에서 새 객체와 저장된객체를 구분할 때 null 을 본다고 들었습니다.그래서 참조형 Long을 쓰는 구나 라고 생각을 정리했어요!! 헌데 코틀린으로 쓰신 코드에서는 Long타입을 선언하시고 0으로 초기화해주시는 이유가 궁금합니다!코틀린에서는 nullable하게 할순있지만 기본적으로 null이 불가능하다고 들었긴한데.. 조금 헷갈립니다!언어적인 부분에서 jpa가 다르게 동작하는것인지 아니면 제가 좀 미숙하게 이해한건지 궁금합니다!

안녕하세요, 좋은 강의 만들어주셔서 정말 감사합니다!!이번에 신규 기능을 추가하면서 통계 데이터도 필요한 상황인데 통계 데이터에 사용되는 원본 데이터가 수정되는 케이스는 어떻게 설계하는게 좋을지 조언을 구하고자 질문드립니다.통계 데이터는 유저가 조회하고, 데이터 조회 기간은 최근 7일/최근 한달/과거 한달(사용자 조정 가능)로 조정이 가능하고, 한 화면에 4가지 유형의 통계 데이터를 제공해야 해서 이를 위해 일별 통계 테이블을 사용하려고 했는데요.그런데 원본 데이터가 언제든 수정되거나 추가될 수 있는 상황입니다.그래서 수정한 사용자와 수정 일자를 따로 모아 배치를 돌리는 방향이 생각났는데 이렇게 설계해본 경험이 없어,우선은 실시간 증분 업데이트를 진행하고 데이터 정확성이 필요해지는 상황이 필요하다면 그때 위와 같은 배치를 돌리는게 나을지 또는 다른 방향이 있을지 궁금하여 질문드립니다.정산 데이터는 아니기 때문에 멱등성이 깨질 수 있는 상황은 감안하고, 기획 요구사항인 실시간성을 반영하는게 좋을지도 고민이 되어 질문드립니다!

28강 sql 파일 어딨나여?

이번에 취업한 회사에서 SQL이나 DB에 관련된 역량이 더 필요할 것 같은데DB는 오라클을 주로 쓰더라구요.오라클이나 MySQL이나 강의 내용이 상관없을까요?

안녕하세요. 강의를 듣다보면, 집합 레벨의 변화에 대한 내용이 많이 나오는데요.'1:m조인 시 결과집합은 m집합의 레벨을 그대로 유지'에서'm집합의 레벨을 그대로 유지'한다는 의미를 아래 두 가지와 동격으로 이해해도 괜찮을까요? = m집합 테이블의 '행 개수' 유지 --- (1)= m 집합 테이블의 'pk의 unique 수' 유지 --- (2)

제미니님 이커머스 강의와 프로젝트 코드들을 참고하면서 게시판을 만들어보고 있는 중입니다!현재는 게시물 정보만 페이징 방식으로 구현해놓았습니다.근데 게시글 목록을 보여줄 때 한 게시글 당조회수, 좋아요수, 댓글 수, 유저닉네임 등.. 표시가 되야해서 좀 헷갈립니다.  한 API에서 전부 조합해서 내려준다고하면페이징된 게시글 10개를 먼저 조회하고조회한 게시글의 ID를 기반으로 조회수와 좋아요를 따로 조회한 뒤에 같이 내려주는 방식이 좋을까요?  

안녕하세요 미국 달팽이님! 강의 잘 듣고 있습니다.https://inf.run/JxEdX에서 안내주신 구글 폼 링크로 수강 닉네임과 substack 이메일을 제출했는데, 혹시 제가 입력한 정보가 잘못됐을까요? 확인 한번 부탁드립니다.!

2NF를 충족하기 위한 조건은 다음과 같은 것으로 알고 있습니다.제1 정규형을 만족하고,모든 컬럼이 후보 키 전체에 완전 함수 종속되어야 한다. 예를 들어 수강 테이블의 컬럼이 다음과 같다고 할 때,id: PK [대리 키]student_id: UK1 [자연 키]course_id: UK1 [자연 키]student_name [일반 컬럼]후보 키:id [기본 키 - 단일 후보 키](student_id, course_id) [대체 키 - 복합 후보 키] (student_id, course_id)는 복합 후보 키이고,student_id -> student_name (부분 함수 종속)이므로 2NF에 위배되지 않나요?따라서 대리 키만 써도 2NF에 위배되는 일이 발생할 수 있다고 생각합니다. 아니면, 실무에서는 2NF의 정의를 기본 키에만 한정하여 2NF를 만족하는 것으로 보나요?   

안녕하세요. 이틀 전에 "[인프런] 제미니 개발실무 수강생 전용 Junie 이용권 증정"라는 제목으로 메일이 왔는데요.JetBrains의 후원으로, 강의에서 활용하는 AI 개발도구 Junie를 체험해 볼 수 있는 All Products Pack 3개월 이용권을 제공받기 위해 구글폼을 통해 신청하면 확인 후 쿠폰 코드를 발급해 주신다는 메일을 받았습니다.마감이 오늘까지라서 오늘 구글폼으로 들어가 봤더니 선착순 신청이 마감되어 조기 종료되었다고 뜨고 있습니다. 메일 내용으로 봤을 땐 선착순이라는 내용은 없었는데, 혹시 신청할 수 없는 걸까요?

Redis Pub/Sub 구독을 통해 Redis 갱신 시 Sub로 구독 중인 각 서버에 캐시 무효화 및 강제 갱신 시키는 구조는 잘 안쓰이나요?이 방법도 네트워크 순단 시 fire and forget, 구현 복잡도가 높음 등의 문제가 있긴한데 실무에서는 Pub/Sub을 잘 안쓰는지 궁금합니다.

제미니님 안녕하세요. 강의를 통해 각 개념 간의 응집성을 높이고, 불필요한 의존성을 줄여 격벽을 세우는 설계를 깊이 있게 연습하고 있습니다.강의에서 배운 원칙을 적용하여 '리뷰'나 '찜' 같은 개념들이 '상품' 개념을 단방향으로 참조하도록 구조를 잡고 있습니다. 하지만 실제 상품 목록 조회 기능을 구현하다 보니, 설계의 일관성을 유지하기 어려운 상황을 마주하게 되어 조언을 구하고자 합니다.개념 간 의존성의 역전: 목록 화면에서 '리뷰 수'나 '찜 수'를 함께 보여주거나, 이를 기준으로 상품을 정렬해야 하는 요구사항이 생겼습니다. 이 경우 상품 개념이 본래 몰라야 할 하위 개념(리뷰, 찜 등)의 상태를 알아야만 하는 상황이 발생합니다.API 구성의 어려움: 상세 페이지는 API를 잘게 나누어 클라이언트에서 합성함으로써 개념 간의 독립성을 지킬 수 있지만, 목록의 경우 수십 개의 상품에 대해 매번 각각의 리뷰 수 API를 호출하여 클라이언트가 매핑하는 방식은 어딘가 어색하고 성능과 구현 효율 면에서 의문이 듭니다.결국 조회를 위해 상품이 다시 리뷰나 찜을 알게 되면, 처음 설계한 개념 간의 단방향 참조 구조가 깨지거나 서로를 참조하는 순환 참조가 발생할 것 같아 우려됩니다.이처럼 개념 간의 격벽을 유지하려는 설계 원칙과, 여러 개념의 데이터가 한꺼번에 필요한 조회 요구사항이 충돌할 때 어떤 식으로 접근하는 것이 현명할까요? 원칙을 고수하며 우회할 방법이 있을지, 혹은 이런 조회 상황에서는 설계적 타협이 필요한 것인지 견해를 듣고 싶습니다.

안녕하세요 단건데이터(ex: 로그) 처리의 경우에는 크게 고민하지 않고 MERGE를 사용하여 처리하고 있습니다. 하지만 10~20건 이상의 데이터셋이 들어오는 경우에는 어떤 방식으로 처리하는 것이 더 적절한지 고민이 되어 질문드립니다. 데이터 DELETE -> INSERT 2번의 쿼리 수행(또는 BEGIN으로 1번에 수행)  데이터 STATE (I, U, D 등)를 활용하는 방식 화면에서 데이터에 INSERT / UPDATE / DELETE 상태값을 기반으로 서버에서 DELETE 1회, INSERT 1회, UPDATE N회를 수행실무에서는 작업 공수 문제로 1번 방식(DELETE -> INSERT)을 선택하는 경우가 많았습니다. 다만 이 방법을 사용하면서 DELETE로 인해 발생하는 DB 블록 낭비기존 데이터의 CREATE_DATE가 유지되지 않아 UPDATE_DATE와 의미 차이가 사라지는 문제데이터 관리, 유지보수, 성능 측면에서 어떤 방식이 더 바람직한 선택인지 궁금합니다.