AI로 코드를 분석해보거나 레거시의 수정 포인트를 느껴보거나 하는 부분은 많이 와닿았는데요. AI 가 코드를 수정한 이후에 코드를 비교해보는 영역에서 브랜치를 어떻게 관리하는게 좋을 지 의문이 들었습니다. AI 가 다수의 코드를 변경하고 있는데, 실제 실무에서는 한 꺼번 에 코드를 바꿔버리면 diff가 너무 많아서 개발시 우려되는 부분이 많이 생깁니다. gpt에 물어보면 ai/product-draft 와 같이 실험용 브랜치에서 작업 이후에 선별하여 수정하라는 답변을 받았는데요. 아직 섹션3을 수강하고 있어서, 이른 질문일지 모르지만 해당 사항 관련하여 실무적인 관점에서 실제로 어떻게 하는게 좋은 방법일 지 조언 한 번 부탁드립니다.
안녕하세요, 이번 강의를 듣고 아주 간단한 질문을 남깁니다. Soft Delete + 이력 테이블 설계가 필요한 이유가 외래 키 제약 조건으로 인한 삭제 어려움 때문이라 이해했습니다. 일부 실무자들은 이러한 삭제 불편함으로 인해 물리적으로 외래 키 제약조건을 DB에 걸지 않는다는 말을 들은 적이 있는 것 같은데요, 만약 그렇게 제약이 없다면 단순히 Hard Delete + 이력 테이블 구조로 고정해도 괜찮은 걸까요?
어노테이션 뭐가 있는지 궁금했습니다. 스프링 공식 문서( https://docs.spring.io/spring-framework/reference/index.html )에 Annotation 검색해보니까 여러가지가 나오네요. 어떤 걸 봐야 어노테이션 전체를 볼 수 있나요? 어노테이션 페이지가 따로 없나요?
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 primary key 로 where 절에 넣고 select 를 하면 key 에 primary 가 찍혀 효율적인 조회가 가능하다고 알고있습니다! 그런데 수업 내용에서 EXPLAIN SELECT item_id, price, item_name FROM items WHERE price BETWEEN 50000 AND 100000; 해당 쿼리를 사용하면 extra 에 Using index condition 나와 인덱스를 사용해서 구했다 < 까지는 이해가 가는데 여기서 item_id 라는 primary key 가 존재하는데 이거로 db 접글을 재시도하면 어째서 랜덤i/0가 발생하는건지 궁금합니다.
강사님 안녕하세요. 쿠폰 조회 로직 구조 관련해서 의견 여쭤봅니다. 현재 제 구현은 findBestBenefitCoupons 에서 DB(Querydsl) 쿼리 하나로 - 대상 필터링(INCLUDE/EXCLUDE, 기간, 상태), - 할인금액 계산, - 적용가능 여부 정렬, - 페이지네이션(Slice) 까지 전부 처리하고 있습니다. 그런데 쿼리가 너무 복잡해져서, “DB에서는 가능한 필터링/후보 추출만 하고, 복잡한 적용 규칙/최종 정렬은 애플리케이션 레이어에서 처리”하는 방식으로 바꿔도 괜찮을지 고민 중입니다. 제 가정은 사용자별 쿠폰 수가 많아도 수천 장 수준이라 앱 처리도 감당 가능하다는 점입니다. 강사님 코틀린 예제 CouponTargetReader )는 DB는 타겟 조회 중심이고 조합은 앱에서 하는 패턴으로 보였는데, 제 케이스(최적 쿠폰 + 페이징)에도 이 방향이 실무적으로 타당할까요? 아니면 정렬/페이징 일관성 때문에 핵심 랭킹 로직은 DB에 유지하는 게 더 맞을까요? 추가로 궁금한 점이 있습니다. 대규모 커머스 회사에서는 이런 “최적 쿠폰 목록” 문제를 보통 어떻게 처리하나요? 쿠폰 목록은 조건(회원/주문금액/대상/기간)이 많아서 캐싱도 쉽지 않아 보이는데, 실무에서는 어떤 식으로 분리(DB/애플리케이션/배치/사전계산)하고 어떤 기준으로 설계 결정을 내리는지 궁금합니다. 저는 지금 소규모 서비스에서 개발 중이라, 대규모 트래픽/대량 데이터 환경에서의 실무 관점 인사이트를 얻고 싶습니다. 판단 기준(데이터 건수, 성능 임계치, 페이지 정합성, 운영 복잡도)도 함께 조언 부탁드립니다.
date_part의 결과에 대한 data type을 출력해 보니 "double precision"으로 나옵니다. 저는 date_part에서 추출한 part가 예를 들어 'month'라고 하면 그 값 자체가 date 유형으로 생각해서 to_char(date_part('month', hiredate), 'month')의 결과가 'january' 로 기대했는데, 오류가 나오더라구요.
안녕하세요. 주문, 상품과 같은 비즈니스에 중요한 데이터를 전체 행 스냅샷 이력 테이블 로 관리 하는 상황일 때, 대상 테이블(주문, 상품 등)의 칼럼이 추가/삭제되는 상황에 이력 테이블에 어떻게 반영해야할지 질문 드리고 싶습니다. - 추가: 신규 기능으로 인해 새로운 칼럼 추가 - 삭제: 기획 변경으로 오랜 기간 미사용 칼럼으로 낭비되어 삭제로 결정된 경우 등
안녕하세요! 강의를 다 보고 이 프로젝트를 제 손으로 다시 작성해보려고 합니다. 코드를 눈으로 쭉 봤지만 SQL, 데이터베이스 구조 등은 정확히 들여다보지는 않았기 때문에... 무엇보다도 코드를 느끼려면 다시 작성해보고 테스트도 보고 그러는게 좋을 것 같아서요. 완전 같게 작성하기 보다는 강의에서 해주셨던 부분들 개선해보거나 바꿔보거나 하려고요 저는 python 개발자이기 때문에 Spring 대신 FastAPI, JPA 대신 sqlalchemy 를 사용하려 합니다. 작성하려고 보니 어떤 순서로 작성하는 것이 좋을까 질문 드려도 되나 싶어서 질문 올려봅니다. 일단 제 생각에는 v1/products 부터 시작 하려고 하는데 우선은 프로젝트 구조부터 간단히 잡고 그 다음은 도메인 클래스, 엔티티, productService, controller 순서로 구현/테스트 코드 작성 v1/products 가 완성되면 서버 실행해서 동작 확인 그 다음은 뭐 v1/products/{productId} 이런 순서로 작성해보려고 하는데요 재민님은 혹시 이 프로젝트 만들때 어떤 순서로 구현하셨는지? 혹시 테스트부터 시작 하시는지? 처음 시작할 때 의 팁 있으시면 공유 부탁 드립니다 좋은 강의 감사합니다!
강의에선 되게 단순하게 큰 틀 위주로 알려주시는 것 같아서 개인적으로 더 자세한 의미나 추가적인 개념이 궁금할 때 검색해보는 편인데, DI라는 것이 클래스 간의 결합도를 낮추고 객체의 유연성을 높이기 위해 빈 객체를 만들어 주입하는 것을 의미한다고 정리했습니다. 이게 맞게 정리한건지 궁금합니다. 또 추상 클래스와 인터페이스 간의 차이점은 찾아봐도 이해가 어렵길래 선생님의 친절한 설명이 필요할 것 같아서 추가로 여쭤봅니다!
안녕하세요 영한님. 강의 정말 잘 듣고 있습니다. common_code_detail 은 pk로 natural key(group_code, code) 를 사용하는 것이 정형화되어 있다고 하신 부분을 이해했습니다. 서비스를 운영하다 보면 code의 값을 수정할 경우가 생길 가능성이 있을 거 같은데요. 예를 들면, 다음과 같은 요구사항이 있을 거 같습니다. group_code가 ORDER_STATUS 인 code에 대한 변경 요청. SHIPPING 을 두가지 상태로 확장(SHIPPING_START, SHIPPING_COMPLETED) 변경 전의 SHIPPING은 SHIPPING_COMPLETED로 취급한다. 설계 1편의 "pk는 immutable해야한다" 라는 3번째 규칙이 있었는데요. 공통 코드 테이블의 경우에는 3번째 규칙을 유연하게 적용해야하나? 하는 생각이 들었습니다. 공통 테이블은 natural key를 사용하니 어느정도 허용을 한다고 보면 될까요? 아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요. 실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.
이번 강의의 수업자료 pdf 보니, 제목 클릭 시 링크위치가 각 챕터가 아닌, 마지막 페이지 정리 내 제목들로 이동합니다. 9. 논리적 모델링 - 실습.pdf 파일 제외하곤 모든 파일의 목차들이 다 마지막 정리로 이동하더라고요. 그동안 영한님 강의들 자료에는 각 챕터로 쉽게 이동 하기 좋았거든요. 이부분이 개선 가능할까요? 이 상태여도 학습은 가능한데, 건의드립니다. 감사합니다.
강의 잘 듣고 있습니다! 수강중 궁금한 내용이 있어서 남겨요. CartItem 개념객체가 ProductOption을 알고 있지만 CartItemResponse를 보니 장바구니에 노출 시켜줄 때는 오직 Product의 가격으로만 노출 켜주고 있더라고요. 장바구니에 담기는 단위, 기준이 ProductOption이지만 CartItemResponse에서는 product의 가격으로 노출 시키고 있는 이유가 궁금합니다! 또한 ProductOption의 Price는 Product의 Price와 별개로 봐야 하는건가요? 그리고 ProductOption 단위 하나로 옵션개념이 잡혀있는 것 같은데 (ex: 색상:REDㅣ사이즈:M), 만약 이 옵션들이 하나의 단위가 아닌 개별로 데이터를 가지게 된다면 어떻게 해야할까요? (ex: 색상:RED +3000원 - 사이즈:M +500원) (ex: 색상:BULE +3000원 - 사이즈:M +1000원)
