173만명의 커뮤니티!! 함께 토론해봐요.
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
유니크 제약조건에 대해 질문드립니다. 예를 들어 핸드폰 번호당 계정을 하나만 가질 수 있어서 핸드폰 컬럼을 유니크제약을 걸었습니다. 특정 회원이 탈퇴할 때 하드 딜리트가 아니라 소프트 딜리트를 하는 정책일 경우, 탈퇴 했던 유저가 다시 가입하게되면 어떻게 해줘야할까요.? 그럼 결국 유니크 제약을 디비에서 없애고, 애플리케이션 단에서 제어를 해야할까요?
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
제미니님 안녕하세요 ! 강의 수강 중 Product와 Category간 개념 정리네 대해 질문이 있습니다 ! 강의를 들으면서 Product와 Category에서 Product가 상위의 개념이라고 선택하시고 매핑 테이블을 네이밍을 ProductCategory을 사용하셨다고 이해하고있습니다 ! 그런데 개념도를 봤을때.. 개념 간 매핑해주는 ProductCategory가 Product 개념 영역에 있는게 맞는지 의문이 들었습니다 ! Category가 Product 하위의 부가적인 정보로서 ProductCategory가 Product 개념 영역에 존재할 수도 있지만.. 강의에서 설계하는데 있어 Product가 상위 개념으로 판단을 했고, ProductCategory는 Category에 대한 부가정보인데 상위 개념이 하위 개념에 대한 것을 모르도록하는게 맞지 않나 라는 생각이 들어서 질문드립니다 !
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요! 평범한 대학생 백엔드 개발자 입니다! 저희 대학생에게 맞는 강의 영상 찍어주셔서 감사합니다 :) 다름이 아니라 도메인 계층에서 Page를 사용해도 되는지 의문이 발생했습니다. 제가 인지한바로는 도메인 계층은 순수한 로직이 이루어져야한다고 알고 있습니다. 그래서 저는 도메인 계층에서 Page에 관한 DTO를 하나 생성하고 스토리지 모듈에서 해당 DTO로 반환하게 코드를 작성하였습니다. 그런데 강사님의 코드를 보니까 도메인 계층에서 Page를 사용하고 있더라고요... 단순한 트레이드 오프일까요? 클린 아키텍처와 회사 내 규칙을 따를 것이냐 아니면 개발 편의성을 위해 Page만 허락한다는 등... 그런 것들이 존재할까요? 그렇지만 도메인 계층에서 스프링 프레임워크에 대한 의존성을 갖는게 되지 않을까요... 잘 모르겠습니다! 이렇게 생각하는게 좋은 방향일까요? ㅠㅠ (추가로 도메인 계층에서 Page를 사용할 시 테스트 코드는 어떻게 작성하나요?)
해결됨
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
정규화와 정규형을 생각할 때는 자연키를 사용한다는 것을 가정해야할까요? 예를 들어, 회원 테이블을 회원id (대리키), 아이디(자연키), 비밀번호, 이메일 속성으로 정의할 때, 회원id 는 아이디를 결정하고 (회원id -> 아이디), 아이디는 비밀번호, 이메일을 결정하므로 (아이디 -> 비밀번호, 아이디 -> 이메일) 이행함수 종속이 발생하는 것처럼 보입니다. 이처럼 정규화와 정규형을 생각할 때에는 대리키 개념을 배제하고, 자연키를 기준으로 생각해야할까요?
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
강사님이 추구하시는 생각하는 공부에 대해서 많이 고민해보게 되었습니다. 그렇다면 강사님이 생각하셨을 때, 이 강의를 보고 공부하는 이상적인 방법은 어떤게 있다고 생각하시나요? 예를 들면, 하나의 섹션을 먼저 다 보고 요구 사항 정리부터 다시 시작해보기 아니면 각 강의마다 끝나고 요구사항을 정리해보고 다음 넘어가기.. 등등 강사님도 커리큘럼을 만드실 때 이런식으로 하면 좋을 것 같다가 있으셨을 것 같은데 궁금합니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요. 결제 부분 강의를 보니 payments API를 보면 컨트롤러에서 주문을 조회하고, 사용 할 쿠폰을 조회하고, 포인트를 조회하고, 조회 된 데이터를 PaymentService로 전달하는 스타일이더라구요. 제가 진행중인 사이드 프로젝트도 커머스가 주제입니다. 제 프로젝트도 처음에는 강의 코드 스타일대로 컨트롤러에서 필요한 데이터를 조합하고, 결제를 처리하는 Service 쪽으로 넘기는 형식이었는데, 이게 점점 결제 기능이 고도화되면서 뭔가 컨트롤러에서 비즈니스 로직의 흐름이 보이는게 맞나? 라는 생각이 들게 되었고 어느 순간부터 웬만한 Controller에서는 1개의 xxxService.method()만 호출하고 이 method가 요청에 대한 비즈니스 로직을 전부 담당하게 되었습니다. @Service class QuestionPaymentService( private val questionOrderGenerator: QuestionOrderGenerator, private val promotionApplier: PromotionApplier, private val orderCouponApplier: OrderCouponApplier, private val paymentCouponApplier: PaymentCouponApplier, private val questionPaymentRecorder: QuestionPaymentRecorder, private val pointCommandAPI: PointCommandAPI, private val eventPublisher: EventPublisher, ) { @Transactional fun payment(command: QuestionPaymentCommand): QuestionPayment { val order = questionOrderGenerator.generateQuestionOrder(command.userId, command.questionIds) val questionPayment = QuestionPayment.create(command.userId, order) promotionApplier.apply(order) orderCouponApplier.apply(questionPayment, command) paymentCouponApplier.apply(questionPayment, command) pointCommandAPI.usePoint(questionPayment.userId, questionPayment.realAmount) questionPaymentRecorder.record(questionPayment) eventPublisher.publish(toEvent(questionPayment)) return questionPayment } } 위 코드는 제 프로젝트의 결제 부분인데요. 강의에서 말씀하신 것처럼 Service가 너무 많은 걸 알게되더라구요. (주문도 생성하고, 쿠폰도 적용하고, 프로모션도 적용하고...) 지금 이 글을 작성하다보니, 갑자기 제 코드가 못생겨보이네요 .. 강의 코드와 비슷한 방식으로 위 코드를 바꿔본다면, 컨트롤러에서는 orderService를 이용해서 주문을 생성하고, couponService, promotionService 등을 이용해서 전처리를 한 뒤 PaymentService을 이용해 실 결제 금액만큼 금액을 지불하도록 하는 로직과 결제 내역을 저장하는 로직만 있을 것 같아요. 반대로 제 프로젝트 방식대로 강의 코드의 payments API를 만들어본다면, Payment를 만들기 위해서 PaymentCreateService와 같은 곳에서, orderReader, ownedCouponReader, pointReader 등을 조합해서 Payment를 생성하는 방식이 될 것 같아요. 결국 Service가 적은 책임만 가지게 된다면, Controller 입장에서는 복잡한 요청을 처리하기 위해선 다양한 Service를 조합하게 되고 Controller가 비즈니스 로직의 흐름을 보여주는 형태가 될 수 있다고 생각이 드는데요. ( 사실 Controller가 비즈니스 로직의 흐름을 보여주면 안된다는 걸 어디서도 듣지 않았지만 뭔가 어색한 것 같아요. ) 물론 계속 말씀하시는것 처럼 정답은 없다는 것은 알지만, 그냥 단순히 재민님은 주로 많은 책임을 가지는 Service보다는 Controller에서 작은 단위의 Service로 조합해서 처리하는 것을 선호하시는지 궁금합니다. 재민님을 지속 성장 가능한 소프트웨어 포스팅으로 알게되었고, 유튜브에서도 많은 도움이 되었어요. 그렇게 얻은 다양한 인사이트들을 개인 프로젝트에도 적용해보면서 다양한 시도를 하고 있는데 마침 제 관심사인 커머스 주제로 강의가 나와서 정말 행복합니다.
미해결
김영한의 실전 데이터베이스 - 기본편
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 안녕하세요 영한님, 강의 정말 재밌게 봤습니다! 다름이 아니라 문제와 풀이 3번 문제 "RIGHT JOIN으로 주문 없는 고객 찾기" 를 보면 '가입은 했지만 주문 기록이 없는 고객의 이름과 이메일을 조회하는 SQL을 작성하라고 되어있는데, DISTINCT 를 붙여 중복을 제거한 행을 조회하는게 맞는게 아닌가 싶어 질문 드립니다!! -- 기존 답안 SELECT u.name, u.email FROM orders o RIGHT JOIN users u on o.user_id = u.user_id WHERE o.order_id IS NULL; -- 제가 생각한 쿼리문 SELECT DISTINCT u.name, u.email FROM orders o RIGHT JOIN users u on o.user_id = u.user_id WHERE o.order_id IS NULL;
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
결제와 주문, 배송과 주문 관계까 1대1인데 결제, 배송 쪽 관계 표시가 선택적1로 되어 있는데 잘못된거 아닌가요'?
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
사이드프로젝트로 백엔드 시스템을 개발할때 어떤 순서로 해야되나요? 데이터베이스 설계를 먼저 한 뒤에 코드작성을 시작해야되나요? 그리고 만약 개발과정에서 처음 설계한 데이터베이스 규칙에 위반되는 코드가 나온다면 어떻게 해야하나요?
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요 영한님. 강의를 들으면서 파편화된 정보를 정리하고 있어 너무 즐겁게 강의를 듣고 있습니다. 그런데 AI 퀴즈를 풀던 중 해당 퀴즈에서 뭔가 의아함을 느껴 질문드립니다. 물론 A를 토대로, 외래 키 컬럼에 NULL을 허용함으로써 선택적 참여를 구현할 수 있다는 것까지는 이해할 수 있겠습니다. 다만 [별도 참여 테이블 생성]이 위에 말씀 주신 member를 생성하는 것이라면 B가 더 적합한 선택지라는 생각이 듭니다. 혹시 [별도 참여 테이블 생성]이라는 선택지는 team / member 외의 테이블을 하나 더 만드는 것을 의미했던 걸까요? 비롯해서 해설에 있는 [맞을까요?]라는 질문이 적절하지 않게 느껴지는데요. 인프런으로 문의드릴까 하다가, 문제에 대한 질문을 드리는 것은 이쪽이 맞을 것 같아서 QnA로 질문드립니다!
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
프론트엔드 개발자와 함께 작업을 하게 된다면 용어 사전같은 프로젝드 관련 파일들을 공유 하는지 궁금 합니다.
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요 영한님!! 강의 복습에 있어 설계 강의는 어떻게 강의 복습을 해야하는지 너무 뜬구름 잡는 기분이라 조언을 얻고자 합니다. 설계라는 게 아직은 멀리 있는 과정이라 생각이 들어서 그런지 더욱 어려운것 같습니다 조언 부탁드려요!
미해결
graphRAG - Neo4J로 구현하는 지식 그래프 기반 RAG 시스템 (feat. LangChain)
프로젝트 4번에서 제공해주는 실습데이터의 zip안에 파일이 존재하지 않습니다. 그래서 법령 사이트 들어가서 pdf로 다운받아서 실습을 진행했는데 결과가 다르게 나옵니다.
해결됨
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
A, B, C 이렇게 세 개의 테이블이 있는데요, A → B, B → C, C → A 이렇게 서로 참조하고 있는 구조입니다. 문제는 이렇게 되어 있으니까, 예를 들어 B를 지우려면 A가 걸리고, A를 지우려면 또 C가 걸리고, C를 지우려면 다시 A가 걸려서 결국 서로 물려서 삭제가 안 되는 상황이 생깁니다. 예를 들면 A = 학생(Student) → 어떤 수업(B) 에 참여하고, B = 수업(Class) → 그 수업은 교사(C) 가 담당하며, C = 교사(Teacher) → 교사는 자신이 가르치는 학생(A) 들의 리스트를 참조(관리용). 이 예시는 정확한 상황은 아니고 제가 생각해서 만들어낸 예시입니다 조금 안맞을수 있는데 만약에 이런 경우에 보통 어떻게 처리해야하나요?
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
어떻게 보면 이 수업과는 조금은 먼 이야기일수도 있는데 실제 프로젝트에서 JPA를 다루다보니 엔티티 선언시에 시간 타입 정의를 어떻게 처리해야 할지가 항상 고민이 되더라구요. 현재 프로젝트에서는 Entity 정의시에는 Instant를 사용을 하는데, 혹시 추천하시는 방법이 있을까요??
미해결
김영한의 실전 데이터베이스 - 기본편
풀 외부 조인을 잘 사용하지는 않지만 가끔 사용하실 때가 있다고 했는데 어떨 때 사용하셨는지 궁금합니다.
미해결
JPA (ORM) 개발자를 위한 고성능 SQL (High-Performance SQL)
안녕하세요, 강의 잘 듣고 있습니다. 좋은 강의 만들어주셔서 감사합니다! 강의에서 JSON 타입을 활용하는 부분이 인상 깊어서, 이를 실무 API 배치 작업에도 적용할 수 있겠다고 생각했습니다. 현재는 API 호출 비용 절감을 위해 응답 데이터를 저장하고 있습니다. 그런데 외부 API는 언제든 스펙이 변경될 수 있어서, '원본 응답을 그냥 JSON 형태 그대로 저장하는 게 낫지 않을까'라는 생각이 들었습니다. 다만 저희는 MySQL을 사용하고 있어서, PostgreSQL의 Materialized View 같은 기능을 직접 활용할 수 없습니다. 대신 MySQL에서 JSON 컬럼을 효율적으로 활용하면서도 백오피스 조회 성능을 보장할 수 있는 방법이 궁금합니다. 예를 들어, JSON 컬럼에 데이터를 저장하면서, 자주 조회하는 필드는 생성 컬럼을 두고 인덱스를 적용하는 방식이 일반적인지, 아니면 JSON은 단순 보존용으로만 두고, 정규화된 별도 테이블을 함께 운영하는 것이 나은지, 또는 다른 고성능 패턴이 있는지 궁금합니다.
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
실무에서도 외래 키(Foreign Key)를 쓸수 있는 상황이지만 특별히 쓰지않고 처리하는 경우가 있을까요? 예를 들어 시스템 초기에 보다 유연한 설계를 위해? 데이터 보전을 위해? 아니면 쓸수 있으면 최대한 쓰는게 맞을까요?
해결됨
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요. 섹션 8에서 장바구니에 주문을 생성할 때 같은 상품이 중복으로 생성되게 하지 않게 제약 조건을 걸었는데 실무에서는 쿼리에서 제약 조건을 거는 지 아니면 애플리케이션에서 - 없을 때 추가 - 있을 경우 수량 증가 와 같이 아니면 비즈니스 로직에서만 처리 하는 지 어떤 케이스나 어느 비율로 적용하는 사례가 궁금합니다.
미해결
김영한의 실전 데이터베이스 - 기본편
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번째 방법을 활용해서 그렇다고 합니다. 그냥 이렇게 알고 있으면 될까요?
