안녕하세요! 연관 엔티티의 네이밍 기준(연결 강조 vs 의미 있는 이름)에 대한 강의를 듣고 고민이 생겨 질문드립니다. 강사님의 조언대로 처음에는 '의미 있는 이름'을 우선적으로 부여하고자 했습니다. 하지만 실제 설계를 진행하다 보니 다음과 같은 딜레마를 겪고 있습니다. 1. 직관성 저하 및 매핑 테이블 식별의 어려움명확한 의미가 떠오르는 것만 의미형으로 짓고, 나머지는 연결 강조형(A_B)으로 설계했더니, 전체 ERD를 볼 때 어떤 테이블이 독립 엔티티인지, 어떤 테이블이 단순히 N:M 관계를 해소하기 위한 매핑 테이블인지 한눈에 파악하기가 어려워졌습니다. 규칙이 혼재되다 보니 오히려 일관성이 무너지는 느낌을 받았습니다. 2. 다중 다대다(N:M) 관계에서의 한계그렇다고 매핑 테이블의 일관성을 위해 모두 '연결 강조형(A_B)'으로 통일하자니, 두 엔티티 사이에 여러 개의 M:N 관계가 존재할 때 문제가 발생했습니다. 예를 들어, User와 Store 사이에 '찜하기', '방문 내역' 등 여러 맥락의 관계가 존재할 경우, 단순한 user_store라는 이름만으로는 이 관계들의 성격을 전혀 대변할 수 없었습니다. 보통 실무에서 이러한 상황일 때, 일관성(매핑 테이블임을 명확히 인지)과 의미(어떤 맥락의 관계인지 표현)를 모두 충족시키기 위해 주로 어떤 네이밍 패턴이나 타협점을 사용하시는지 실무 노하우가 궁금합니다!

안녕하세요, 선생님!6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다.데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지  일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다.  제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.   

col2만 세어야 하니까 3이죠,,?

안녕하세요. 히스토리 테이블 관련해서 질문이 있습니다. 원본테이블에 업데이트 이유를 트랙킹할 필요가 있으면 변경 사유 컬럼들을 추가하라고 말씀주셨는데  생성, 수정, 삭제시 모두 히스토리 테이블에 스냅샷형태로 저장한다면 변경 사유 컬럼들은 히스토리 테이블에만 있는게 좋지 않을까 싶어서 질문드립니다.

2025 환경에서 Express Edition이 설치 안됐던 문제가 생겼어서 해결방법 공유 드립니다. 문제 원인 : SQL Server 2025 Express 설치 중 에러 코드 -2061893607과 함께 "데이터베이스 엔진 시작 핸들을 찾을 수 없습니다."라는 메시지가 발생 1. 섹터 크기 호환성 확인 및 수정 (가장 유력한 원인)최신 Windows와 SSD 환경에서 시스템 섹터 크기가 4KB를 초과할 경우 SQL Server 엔진이 시작되지 않음. 관리자 권한으로 명령 프롬프트(CMD)를 실행.다음 명령어를 입력하고 엔터. fsutil fsinfo sectorinfo C:  DOS 출력 결과 중 PhysicalBytesPerSectorForAtomicity 값이 4096보다 크다면 호환성 문제가 맞다.이를 해결하기 위해 레지스트리를 수정해야 함.  CMD에 다음 명령어를 입력 (한 줄로 입력):REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v "ForcedPhysicalSectorSizeInBytes" /t REG_MULTI_SZ /d "* 4095" /f 컴퓨터를 재부팅한 뒤, 기존에 설치된 SQL Server 관련 항목을 모두 삭제하고 다시 설치. 명확한 원인 : PhysicalBytesPerSectorForAtomicity값은 4096으로 세팅되어있지만PhysicalBytesPerSectorForPerformance 값이 16384(16KB)로 되어 있는 게 문제!! SQL Server는 물리적 섹터 크기가 4KB(4096 바이트)를 초과하는 스토리지 시스템을 지원하지 않음. 현재 사용 중인 최신 NVMe SSD가 성능 향상을 위해 16KB 섹터 방식을 사용하고 있어서SQL Server 엔진이 데이터 구조를 쓰지 못하고 실행에 실패!// 세팅 성공시 CLI 예시 C:\Windows\System32>fsutil fsinfo sectorinfo C: LogicalBytesPerSector: 512 PhysicalBytesPerSectorForAtomicity: 4096 PhysicalBytesPerSectorForPerformance: 4096 FileSystemEffectivePhysicalBytesPerSectorForAtomicity: 4096 장치 맞춤: 정렬됨(0x000) 장치 파티션 맞춤: 정렬됨(0x000) 검색 벌점 없음 자르기 지원됨 DAX 지원 안 함 씬 프로비저닝되지 않음

ProductOption을 fetch해 올때 DB레벨에서 where이랑 orderby를 하지 않고 애플리케이션 레벨에서 코틀린 filter와 sort를 하신 이유가 따로 있을까요? 성능상 DB에서 전체적으로 데이터를 가져오고 인메모리 작업으로 filter와 sort를 하는게 불리하지 않나 싶어서 질문을 남깁니다.

대충 빨리 듣고 필요한것만 정리 하고 넘어가고 싶은데 어렵고 지루하고 졸리고

안녕하세요 강사님,  강사님 설명이 굉장히 상식적으로 자연스럽게 이해가 되다 보니 따로 이해가 어려운 부분 없이강의 후반부까지 잘 따라 왔는데, 어딘가 마음속에서 걸려있던 의문점 하나가 터졌습니다. 예를 들어 35강 19:46 즈음에 카테고리 테이블에 색깔 컬럼을 진짜중복/가짜중복 을 나누는데1. HOME의 색을 YELLOW 로 바꾸면 UNIVERSITY 도 YELLOW로 바뀌는가? -> NO2. HOME의 색인 RED를 '빨강'으로 바꾸면 UNIVERSITY 도 '빨강'으로 바뀌어야 하는가? -> YES이 두가지 해석이 가능할 것 같습니다.. 물론 결과론적으로 머리로는 colors 테이블을 따로 만들어 FK로 연결하는 것이 맞다는 생각이 들지만강사님의 6가지 원칙을 차례로 따라가는데 헷갈림이 있어 질문드립니다. 감사합니다.

요구 사항이 자주 변경되는 것을 가정하는 프로젝트인 만큼 isUnique에 관련된 상수나 Recent day에 관한 상수를 properties로 빼서 yml에 관리하는 방식으로 구현해보았는데. 실무에서는 어떤 경우에 yml에서 관리하는 방식을 고려하고 어느 상황에 그냥 상수를 코드에 남기는지 궁금합니다.

안녕하세요?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 파일 어딨나여?