ProductOption을 fetch해 올때 DB레벨에서 where이랑 orderby를 하지 않고 애플리케이션 레벨에서 코틀린 filter와 sort를 하신 이유가 따로 있을까요? 성능상 DB에서 전체적으로 데이터를 가져오고 인메모리 작업으로 filter와 sort를 하는게 불리하지 않나 싶어서 질문을 남깁니다.
안녕하세요 강사님, 강사님 설명이 굉장히 상식적으로 자연스럽게 이해가 되다 보니 따로 이해가 어려운 부분 없이 강의 후반부까지 잘 따라 왔는데, 어딘가 마음속에서 걸려있던 의문점 하나가 터졌습니다. 예를 들어 35강 19:46 즈음에 카테고리 테이블에 색깔 컬럼을 진짜중복/가짜중복 을 나누는데 1. HOME의 색을 YELLOW 로 바꾸면 UNIVERSITY 도 YELLOW로 바뀌는가? -> NO 2. HOME의 색인 RED를 '빨강'으로 바꾸면 UNIVERSITY 도 '빨강'으로 바뀌어야 하는가? -> YES 이 두가지 해석이 가능할 것 같습니다.. 물론 결과론적으로 머리로는 colors 테이블을 따로 만들어 FK로 연결하는 것이 맞다는 생각이 들지만 강사님의 6가지 원칙을 차례로 따라가는데 헷갈림이 있어 질문드립니다. 감사합니다.
요구 사항이 자주 변경되는 것을 가정하는 프로젝트인 만큼 isUnique에 관련된 상수나 Recent day에 관한 상수를 properties로 빼서 yml에 관리하는 방식으로 구현해보았는데. 실무에서는 어떤 경우에 yml에서 관리하는 방식을 고려하고 어느 상황에 그냥 상수를 코드에 남기는지 궁금합니다.
[리뉴얼] 처음하는 MongoDB(몽고DB) 와 NoSQL(빅데이터) 데이터베이스 부트캠프 [입문부터 활용까지] (업데이트)
안녕하세요? 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를 포함하신 이유가 궁금합니다!
[리뉴얼] 처음하는 MongoDB(몽고DB) 와 NoSQL(빅데이터) 데이터베이스 부트캠프 [입문부터 활용까지] (업데이트)
안녕하세요, 현재 studio 3t 설치하려면 첨부한 이미지에서 다운받는게 맞나요? 근데 개인정보 입력시 이메일 부분에 gmail.com 같은 일반 이메일말고 회사 이메일을 적용해야 next 로 넘어갈 수 있는 것 같습니다. 아직 회사에 다니는 상황이아닌데 다르게 다운 받는 방법 있으면 안내부탁드립니다 .
@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 로 하는 것이 이 필드는 없을 수 있다는 것을 더 명확하게 나타낼 수 있다고 생각했습니다. 좋은 강의 감사합니다!
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
안녕하세요. 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가지 유형의 통계 데이터를 제공해야 해서 이를 위해 일별 통계 테이블을 사용하려고 했는데요. 그런데 원본 데이터가 언제든 수정되거나 추가될 수 있는 상황입니다. 그래서 수정한 사용자와 수정 일자를 따로 모아 배치를 돌리는 방향이 생각났는데 이렇게 설계해본 경험이 없어, 우선은 실시간 증분 업데이트를 진행하고 데이터 정확성이 필요해지는 상황이 필요하다면 그때 위와 같은 배치를 돌리는게 나을지 또는 다른 방향이 있을지 궁금하여 질문드립니다. 정산 데이터는 아니기 때문에 멱등성이 깨질 수 있는 상황은 감안하고, 기획 요구사항인 실시간성을 반영하는게 좋을지도 고민이 되어 질문드립니다!
안녕하세요. 강의를 듣다보면, 집합 레벨의 변화에 대한 내용이 많이 나오는데요. '1:m조인 시 결과집합은 m집합의 레벨을 그대로 유지'에서 'm집합의 레벨을 그대로 유지'한다는 의미를 아래 두 가지와 동격으로 이해해도 괜찮을까요? = m집합 테이블의 '행 개수' 유지 --- (1) = m 집합 테이블의 'pk의 unique 수' 유지 --- (2)
제미니님 이커머스 강의와 프로젝트 코드들을 참고하면서 게시판을 만들어보고 있는 중입니다! 현재는 게시물 정보만 페이징 방식으로 구현해놓았습니다. 근데 게시글 목록을 보여줄 때 한 게시글 당 조회수, 좋아요수, 댓글 수, 유저닉네임 등.. 표시가 되야해서 좀 헷갈립니다. 한 API에서 전부 조합해서 내려준다고하면 페이징된 게시글 10개를 먼저 조회하고 조회한 게시글의 ID를 기반으로 조회수와 좋아요를 따로 조회한 뒤에 같이 내려주는 방식이 좋을까요?
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를 만족하는 것으로 보나요?