GET /v1/shared-carts API 부분의 구현을 보니 CartReader.getCartAccessList 부분이 있는데 cartAccessRepository.findByUserIdAndStatus 메서드를 사용하여 조회하더라구요. 이렇게 되면 내가 만든 내가 소유자인 카트만 조회될 것 같고, 공유 장바구니 참여자 수 만큼 같은 공유카트가 여러개 조회 될 것 같습니다. 결국 소유자 조차도 access 데이터에 추가된다면 cartAccessRepository.findByAccessUserIdAndStatus 를 사용하여 범용으로 사용하는 것은 불가능할까요? 그리고 CartHandler.createCharedCart 부분에는 도구 레이어임에도 불구하고 하나의 트랜잭션으로 두지 않으셨는데요, 카트 생성 이후 나의 접근 권한이 추가 되지 않는다면 카트 리스트에서 볼 수 없을 것 같은데 이 점에 대해서도 의도하신 바가 있는지 궁금합니다! 또한 access 부분에서 DB 유니크를 걸어두었지만 사전 존재 확인이나 멱등처리가 없는 것 같습니다. 개념적인 예외를 사용하지 않고 DB 무결성 예외를 노출시키신 이유가 궁금합니다.
안녕하세요. 강의 잘 보고 있습니다! [실습] WHERE문이 사용된 SQL문 튜닝하기 - 2 해당 강의에서 질문이 있습니다 :) 이전 강의에서 멀티 컬럼 인덱스의 경우, 첫번째 컬럼 기준으로 먼저 정렬하고, 그 다음 두번째 컬럼 기준으로 정렬한다고 배웠던 것 같습니다! 따라서 idx_created_at <-> idx_created_at_department 실행계획 idx_department <-> idx_department_created_at 실행계획이 각각 비슷할 것이라고 예상했는데, 강의에서는 idx_created_at과 두 개의 멀티 컬럼 인덱스 idx_created_at_department, idx_department_created_at 가 비슷하다는 것을 알 수 있었습니다! 이유가 궁금하여 질문 남겨봅니다 !
강사님 안녕하세요! 강의 잘 듣고 있습니다. 너무 좋네요! 😊 [실습] 인덱스 직접 설정해보기/성능 측정해보기 => 실습 중 질문이 있습니다! user.age에 인덱스 생성 전 [2026-07-12 11:51:16] 1,028 rows retrieved starting from 1 in 420 ms (execution: 110 ms, fetching: 310 ms) => 이런식으로 평균 400ms 속도가 측정되다가 user.age에 인덱스 생성 후 [2026-07-12 12:19:48] 1,028 rows retrieved starting from 1 in 510 ms (execution: 11 ms, fetching: 499 ms) [2026-07-12 12:19:59] 1,028 rows retrieved starting from 1 in 339 ms (execution: 9 ms, fetching: 330 ms) [2026-07-12 12:20:09] 1,028 rows retrieved starting from 1 in 329 ms (execution: 7 ms, fetching: 322 ms) 인덱스 생성 후 최초 실행시에 510ms로 시간이 한번 튀는데 검색해 봤을때는 인덱스 생성 직후 캐싱 되어있지 않아서 발생하는 현상이라고 하는데 이러한 것은 신경쓰지 않아도 되는지 궁금합니다! 감사합니다!
학습 관련 질문을 남겨주세요. 구체적으로 적을수록 좋아요! 실습중에 궁금한점이 있으시면 erdcloud 링크를 첨부해주세요! 데이터 모델링 설명중에 나오는 '용어'들은 강의나 책마다 조금씩 다를 수 있습니다. https://drive.google.com/file/d/1ImDk6PSaolScBZnvEw_Y_Y8Kzxh7wvZd/view?usp=sharing 질문 내용 안녕하세요, 강사님. DAP 시험을 준비하며 강의를 수강하고 있는 수강생입니다. 관계 도출 부분에서 막히는 지점이 있어 질문드립니다. '물류운송시스템' 문제의 화물운송스케줄 엔터티 관련 질문입니다. 화물운송과 운송수단스케줄이 M:M 관계라고 판단하여, 식별자를 운송번호 + 운송스케줄번호 + 운송순번 으로 도출했습니다. 그런데 답안에서는 운송출발순번 과 도착운송순번 두 개의 속성이 식별자에 포함되어 있었습니다. 하나의 화물이 특정 스케줄 내에서 출발 경유지와 도착 경유지를 함께 가져야 한다는 점 때문에 순번이 두 개로 나뉜 것인지 궁금합니다. 이런 경우를 어떤 기준으로 판단해서 식별자를 도출해야 하는지 설명 부탁드립니다. 감사합니다.
AI 시대에도 살아남는 엔지니어의 조건, 미국 빅테크 시스템 디자인, 알고리즘 사고, 오픈소스 실무 완성
안녕하세요 수업 내용중에 포함된 Slide와 설명이 맞지 않는 부분이 있는거 같아서 문의 드립니다. 영상에서는 단점으로 Vertical scaling만 가능하다고 언급하셨는데, 슬라이드에서는 수평적으로만 확장이 가능하다고 하셔서요. 제가 생각하기에도 하나의 코드 베이스에서 모든 기능이 작동해야하다 보니 Vertical scaling이 맞는거 같고 Slide내용이 잘못된거 같은데, 제가 잘못이해하고 있는것인지 확인부탁드리겠습니다. 이제 막 시작했지만 열심히 완주해보겠습니다. 감사합니다.
강의에서 배운 모델링을 바탕으로 프로젝트를 진행하려고 하는데 궁금한점이 생겼습니다. 1:1 관계인 orders 테이블과 delivery, pay 테이블의 관계에서 외래 키를 보조 테이블에 두었는데, jpa를 이용한 애플리케이션 코드에서는 일대일 관계에서 대상테이블에 외래 키를 두었을때 즉시로딩으로 N+1 문제가 발생할 수 있어서 orders엔티티에 외래 키를 두었습니다. 이때 db와 애플리케이션 간에 테이블 구조가 불일치하기 때문에 오류가 발생할 것으로 예상됩니다. 이 경우 주문과 배송, 결제 정보가 같이 생성된다고 보고 외래 키 위치를 주 테이블에 두어야할까요? 아니면 애플리케이션 코드에서 즉시로딩 문제를 해결해야할까요?
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (강의 실습이후 발생되는 상황 ) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 세션 10. 데이터 무결성 - check 제약조건을 설명하기 위해서, orders 테이블이랑 products 테이블을 지우셨습니다. 사진 처럼 요 그 이후에 워크벤치를 껏다 킨 이후에 my_shop2 db를 보니 my_shop 랑 다르게, @@@ could not be fetched 라는 내용이 발생한다는 것을 알수 있었는데요. orders에 있던 여러 내용 들이 없어져서 이런 문제가 났겠다는 것을 알 수 있었습니다. 이런 경우 view에 남아있는 ordes랑 연결되어있는 조건들때문에 문제가 생겼으니 view에 대한것들을 없애면 원래대로 되는지 알고싶습니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 'case문 - 문제와 풀이 - 1번 문제'에서 영한님은 사진 위쪽 부분 case 문 옆에 category 를 써서 단순 case문으로 해결 하였는데요. 여기서 저는 사진 아래쪽 부분에 적힌대로 category = '전자기기' 를 써서 해결하였습니다. 여기서 질문 입니다. category = '전자기기' 이 코드 처럼 해도, 상관 없는지 알고 싶습니다. + 아래 처럼 한 이유는 위에 쿼리문은 완전히 생각이 안났습니다.
안녕하세요 ^^ 아주 작지만 소소한 정오표 전달드립니다. 7. 논리적 모델링3 - 일대일, 다대다 관계 49페이지 AS-IS 우리가 실제 '수강신청 시스템'을로 만든다고 TO-BE 우리가 실제로 '수강신청 시스템'을 만든다고 마우스 드래그 하는 중에 바뀌는 부분 확인했습니다! 항상 감사합니다!
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. mysql 워크벤치를 실행 할때 오류가 떠서 질문을 남깁니다. 사진처럼 이렇게 나옵니다. 그래서 맨 처음 에는 '리스토어 워크벤치 오류' 을 치고 따라 해보았지만, 컴퓨터를 다시 키고 워크벤치를 실행하면 이사진 속 에러가 계속 나옵니다. 어떻게 해야 해결이 가능할까요? + 취소 하고 하면 sql 은실행 가능 합니다. 답변 부탁 드립니다.
graphRAG - Neo4J로 구현하는 지식 그래프 기반 RAG 시스템 (feat. LangChain)
시멘틱 온톨로지 구축을 위해 데이터를 먼저 공부하고있습니다. RAG는 구축된 데이터가 들어간걸 조회할 때 쓰는거라고 생각하고있습니다. 온톨로지 구축을 위해 원천데이터 자체를 분석해서 도메인 사전을 만들어야한다는것을 알고있는데 이걸 어떤식으로 구조화해서 구축해야하는지가 감이 안옵니다. 정규식으로는 한계가 있을 것 같고 LLM으로 하자니 할루시네이션 등의 문제가 발생할 여지가 있고요 이런 관련된 강의를 진행하시거나, 제가 강사님 3가지 로드맵을 다 구독중인데 3개중 볼만한 강의가 있으면 회차좀 가이드부탁드립니다..
안녕하세요 선생님, 실제 필드에선 클라이언트의 요구 사항이 명확하지 않고, 기획자가 없으며, 개발자가 대부분의 일을 다 해내야 하는 경우가 있는데, 클라이언트(대표님 또는 상사)와 소통, 기획서 작성, 설계, 개발까지 혼자 하게 될 때 현명하게 대처하는 방법은 뭐가 있을까요? 큰 기업은 각자의 업무에 집중할 수 있겠지만, 작은 기업은 그게 쉽지 않은 걸 알고 있습니다 클라이언트와 소통, 화면 기획 및 요구 사항 작성등은 어떤식으로 공부해야할까요?
안녕하세요. 공통 코드와 계층 구조 관련해서 질문이 있어 질문 드립니다. 이전에 경험했던 프로젝트 보면 공통 코드와 계층 구조 테이블을 다 합친 일명 '만능 코드 테이블' 에 모두 넣고 사용하는 방식도 사용했는데 이번 공통 코드(자연키, 복합키) 강의와, 계층 구조의 강의를 들으며 시야가 또 달라지네요. 예를 들면 주문 상태 코드와, 상품 코드를 하나의 테이블의 대체키, 외래키를 적용해서 사용했었네요. 혹시 '만능 코드 테이블'의 경우는 추후 유지보수와 개발 편의 관점에서 개선해야하는 부분이 맞겠지요? 만약에 개선하게 된다면, 어떤 기준으로 나누면 될지. 설계적 관점에 대해 혜안을 듣고 싶습니다. 예를 들면, 공통 코드 테이블 2개와, 계층 테이블 이렇게 두고 계층의 가능성으로 보통 나누는지 궁금하고, 추가로 도메인 성격까지 고려해서 테이블을 또 쪼개는지 등이 궁금합니다. 그리고 CS 팀에서 고객 문의 사항에 문의 유형을 최초 상품, 주문, 배송 이런식으로 공통 코드에 넣어서 사용하고 있었는데, 갑자기 정책이 바뀌면서 주문 하위에 주문 오류, 주문 취소 등 하위 개념이 생기면 계층 테이블로 옮겨야 할 거 같은데 이런 경우는 애초에 기획당시에 개발자가 확장 가능성에 대해 고민을 하고 공통 테이블로 넣었으면 안되는 것인지에 대한 부분도 궁금하네요. 매번 질높은 강의로 도움주셔서 감사합니다!
안녕하세요, 유저 테이블과 구독 테이블 설계 중 해결하기 까다로운 지점이 생겨 질문드립니다. *현재 상황을 보다 이해하시는데 문제가 없으시기 위해 ai로 질문을 정리한점 먼저 말씀드립니다. 1. 현재 상황 및 서비스 정책 유저 테이블: id(PK) , email(UK) / 탈퇴 시 소프트 삭제, 개인정보 보호를 위해 이메일 마스킹 필수. 구독 테이블: 현재 활성화된 구독 정보 딱 1건만 관리 (이력은 별도 테이블 존재). 서비스 정책: 탈퇴 후 동일 이메일로 재가입 시, 기존 로우 복구가 아니라 새로운 로우로 Insert 됩니다. 단, 재가입 시 과거 구독 정보는 그대로 이어받아야 합니다. 2. 제가 고민해 본 방법들과 예상되는 문제점 생각한 방법 1) 구독 테이블이 유저 PK( id )를 외래키로 바라보게 한다. 예상 문제: 재가입 시 유저 테이블에 새 로우가 Insert 되면서 새로운 PK를 발급받기 때문에, 과거 PK를 바라보고 있던 구독 테이블과 연결 고리가 끊어집니다. 생각한 방법 2) 유저 테이블에 '이메일 해시(유니크X)'를 두고, 구독 테이블과 해시값으로 매핑한다. 예상 문제: 해시는 개인정보가 아니므로 탈퇴 후에도 유저 테이블에 남겨둘 수 있어 재가입 매칭은 가능합니다. 하지만 유저가 중간에 이메일을 변경하는 경우 , 유저 테이블의 이메일 해시뿐만 아니라 구독 테이블 및 구독 이력 테이블의 해시값까지 전부 동시 UPDATE 쳐야 하는 번거로움이 생깁니다. 3. 질문 요약 개인정보 보호를 위해 유저 테이블의 이메일 원본은 마스킹하면서도, 재가입 시 동일인임을 식별해 과거 구독 정보를 매칭해 주어야 합니다. 여기에 유저의 이메일 변경 가능성까지 고려해야 하는 상황입니다. 이 경우 구독 테이블의 매핑 키 체계를 어떻게 잡는 것이 가장 깔끔하고 현명한 DB 설계 원칙 일까요? 실무에서 이런 케이스를 해결하는 정석적인 아키텍처 가이드가 궁금합니다!
