안녕하세요, 강의 너무 잘보고있습니다!코드를 살펴보니 궁금한 부분이 있는데 현재 작성된 코드에서는 엔티티 간 연관관계를 맺지 않고 풀어내고계시더라고요!재미니님은 실무에서도 연관관계를 사용하지 않으시는 건지 아니면 고민 포인트(?)를 던져주신건지 궁금합니다!예를들어 Order와 OrderItem 관련해서, OrderService의 서비스 레이어인 create 메서드에서 OrderItemRepository를 사용해 saveAll을 호출하는 방식을 사용하시더라고요!저는 Order가 없으면 OrderItem은 존재하지 않아야한다고 생각해서, OrderItem의 생성을 서비스 레이어가 아닌 Order 엔티티안에서 생성하도록 강제하는 건 어떨까 생각했습니다.방법으로는OrderItem.create() 같은 생성 메서드를 protected로 막는다.OrderItemRepository를 아예 생성하지 않는다.더티 체킹을 이용하여 Order 필드에 있는 List<OrderItem> 컬렉션에 요소 추가로 OrderItem을 save한다.팀 컨벤션을 정한다.정도가 있을 것 같은데... 그렇다면 재미니님은 실무에서도 연관관계를 맺지 않는 방식을 선호하시는 건가요?사실 서비스 레이어에서 직접 호출을 통한 저장이라고 해도 문제는 없겠지만 사용하시는 방식이 궁금합니다! 그리고 추가적으로 주문 시 상품 재고를 차감시키는 메서드를 OrderHandler(OrderManager) 에 private으로 위치시키는 것과 ProductHandler(ProductManager)에 위치시키고 주입받아 사용하는 것중 어떤게 더 나은 방식일까요?private void decreaseProductStock(List<NewOrderItem> newOrderItems, Map<Long, Product> productMap) { for (NewOrderItem newOrderItem : newOrderItems) { Product product = productMap.get(newOrderItem.productId()); if (product.isStockLessThan(newOrderItem.quantity())) throw new ApiException(PRODUCT_QUANTITY_OVER); product.decreaseStock(newOrderItem.quantity()); } }고민이 되는 부분은 예를들어 위와 같은 메서드를 OrderHandler에 두자니 조금 헤비해지는 것 같고, ProductHandler에 두자니 신규 주문 시에만 사용될 것같은데.. ProductHandler에 두는게 맞는지 고민입니다..! 의견이나 힌트 주시면 좀 더 고민해보도록 하겠습니다!

선생님 강의를 보다 궁금한게 있는데 src최상위 경로 main.ts는 nestjs를 실행시키기 위한 시작점이고async function bootstrap() { const app = await NestFactory.create(AppModule); //앱모듈로 부터 모듈들을 확장해나갔음 await app.listen(process.env.PORT ?? 3000); }//nestjs를 실행하는 함수 시작점 bootstrap(); 통해 app.module.ts에는 다른 (posts)모듈을 적어줘서 루트가되는 모듈 같은데posts폴더안에 posts모듈 관련 컨트롤러 서비스(프로바이더 할 거) 이렇게 순서대로 nest가 처리해 주는 건 알 것 같은데 -app.module.ts에서 각 모듈을 연결해주고 서비스나 기능 만들려면 모듈별로 폴더 관리해서 만드는거구나? 이렇게 이해하고있는데 그러면 app.service.ts,app.controller는 지워도되는거 아닌가 생각이 들어서요. -깃허브 레포지토리에 강의 코드 올려주신 거 봤는데 따로 초반 부분이랑 다른 코드가 추가된 건 아닌 것 같고 동일해서요따로 안지우시고 그대로 두신 이유가 있을까요?(기다리면..뒤에 알려주실것 같지만 궁금함을 못참고 여쭤봅니다)(약간 두서 없이 여쭤보는것 같아 죄송합니다.생각보다 쉽지않네요ㅎㅎ)

안녕하십니까 좋은 강의 잘듣고 있습니다.강의를 들으면서 예제 코드도 같이 파악해보고 있는데요repository 조회시 조회한 결과에서 활성 상태를 체크할때 2가지 방법으로 구현이 되어있는 것 같습니다.repository에서 쿼리 메서드로 값 전달 findByXXAndStatus()일단 findByXX로 조회하고 filter에서 isActive 체크 2가지 경우다 결과 자체는 Active인 엔티티를 조회하겠지만, 두 경우를 언제 사용하는 것이 좋은지가 구분이 있을까요?? 일단 저라면 목록을 조회하는 경우라면 1번 방법으로 조회하면 조금이나마 성능 이점이 있을 것 같고, 단일 데이터 조회시에는 1번이나 2번이나 상관은 없을꺼 같다는 생각입니다! https://youtu.be/o5byT9Ha5Tg?si=C1zj8oP8-wSB6g7Y최근에 우테코에서도 softDelete 관련 처리를 엔티티 설정을 통해 하기도 하던데, 제미니님의 의견이 궁금하여 질문드립니다! 감사합니다! ps. 아직 제가 강의를 쿠폰 부분까지 들어서 뒤에서 이에 대한 설명이 나오는지는 확인을 못했어요! 

ProductFinder -> ProductUsecase or ProductUsecase<ProductSection>정의한 곳에 Product 서비스 와 ProductSection 서비스를 갖고 안에서 작업을 해보는건 어떻게 생각하실까요?ProductProductSecion 으로 명명하기에는 애매한 부분이 있어, Usecase라는 단어를 써서중간에 두 서비스만 사용하는 컴포넌트를 하나 두는 것은 어떻게 생각하실까요?혹은 Delegator 를 써서, 이 두 서비스를 의존해서 처리해야 하는 프로세스를 위임해버리는 타입을 하나 만드는겁니다.어떻게 생각하실까요?

1초로하면 현재 성공, 실패 각각 200, 0으로 나오고 2초로 해야 100개 씩 성공하는데 정상인가요?

protoc --go_out=. --go_opt=paths=source_relative \ --go-grpc_out=. --go-grpc_opt=paths=source_relative \ proto/shopping.proto protoc-gen-go: program not found or is not executable Please specify a program using absolute path or make sure the program is available in your PATH system variable --go_out: protoc-gen-go: Plugin failed with status code 1.위 처럼 강사님이 주신 명령어를 입력하니깐 플러그인을 설치하라고 나오더라구요! sudo go install google.golang.org/protobuf/cmd/protoc-gen-go@latest sudo go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest처럼 설치하고!sudo go env GOPATH // Go_경로 sudo cp Go_경로/bin/protoc-gen-go /usr/local/bin/ sudo cp Go_경로/bin/protoc-gen-go-grpc /usr/local/bin sudo chmod +x /usr/local/bin/protoc-gen-go sudo chmod +x /usr/local/bin/protoc-gen-go-grpc하고 하니깐 되더라구요!!강의 잘 보고 있습니다 :)

안녕하세요!궁금한점이 생겼는데요.로직을 수행하는 객체중 어떤것은 xxx서비스 어떤것은 xxx핸들러또는매니저(컴포넌트) 등의 객체로 나눠지는데요. 이에 대한 기준이 있을까요?컨트롤러가 호출하는 객체를 xxx서비스, 서비스가 호출하는 객체를 xxx핸들러또는매니저(컴포넌트)라고 보면 될까요? 그렇다면 컴포넌트는 특정 개념에서의 로직들이 응집되어있는 객체 라고 보면 될까요?

킬구형메타데이터쪽 update를 읽다가 이해가 안가는게 있는데 형이update() 메서드는 매 트랜잭션의 커밋 직전에 호출된다. 단, 처리 도중 예외가 발생하여 트랜잭션이 롤백되는 경우에는 호출되지 않는다. 이는 실패한 처리 내용이 실행 정보에 반영되는 것을 방지한다.라고 했는데 그러면 문제가 생겨서 update를 호출하지 않고 롤백이 됬다고 하면 open입장에서는 실패했는지 안했는지도 모르는거아니야? 실패를 해도 마지막으로 저장된 곳부터 다시 시작하니까 실패를 아예 저장을 안한다는거야?재시작할때 메타테이블에서 execution값을 받아와서 괜찮은건가?

전체보기가 없는 상품들 목록이라면카테고리 프로덕트로 설계하는 방향은 어떻게 생각하시는지요?상품의 전체보기가 없습니다.A-Z까지 모든상품들은 카테고리로로 분류되어있고(=모든 상품들은 카테고리라는 꼬리표를 가집니다)좌측 메뉴탭에서도 카테고리별로 구분이 되어있습니다.해당 상품들을 모두 카테고리별로 선택의 상세보기에 해당상품들이 나열되도록 되어있습니다.이러한 생각은 어떤지 한번 의견 듣고싶어요. 

안녕하세요!강의를 보던 중 ReviewService의 트랜잭션 처리에 대해 궁금한 점이 있어 질문드립니다. addReview 함수에서 리뷰를 저장하는 add()와 포인트를 적립하는 earn() 두개의 중요한 함수를 사용하고 있는데, 이는 각각 별도의 트랜잭션으로 처리되어 리뷰는 저장되고 포인트는 적립되지 않는 문제가 발생할 수 있을 것 같습니다.  현재 설계에서 addReview()에 @Transactional을 붙이지 않은 특별한 이유가 있으신지 궁금합니다. 혹은 만약 의도적으로 별도 트랜잭션으로 분리한 것이라면 그 이유가 궁금합니다. 항상 감사합니다.

안녕하세요, 제미니님.유투브 및 인프런 강의 잘 시청하고 있습니다 :) 인프콘 2024에서 '지속 성장 가능한 설계를 만들어가는 방법' 이라는 주제로 발표해주신 내용이 무척 공감이 되었고, 제미니님 유투브를 찾아봤다가 강의까지 수강하게 되었습니다 이번 강의 내용은 아니지만 인프콘 영상에서 말씀해주신 개념인 '개념' 과 '격벽'을 구체적으로 실무에서 어떻게 사용하면 좋을지를 여쭤보고자 인프런 질문을 통해서 글을 올리게 되었습니다. 편의상 신규 프로젝트를 진행한다고 가정했을때,요구사항을 분석하고 도메인을 구성하는 여러 '개념'들을 나열한다.나열된 '개념'들의 급(1급, 2급, 3급 ..) 을 나눠보고 그룹화 하면서 '격벽'으로 분리한다.'격벽'으로 분리된 그룹이 어떤 개념을 통해서 연결될지 방화벽으로 동작할 개념을 생각해본다. 이는 개념간 무분별한 참조를 막기 위함이다.'개념'들과 '격벽'들을 기반으로 일단 코드로 구현부터 해본다. ('설계를 하지 말고 구현을 먼저' 하는 포인트는 이것)구현하면서 또는 운영하면서 더 나누거나 신규로 추가할 개념이 있다면 반영한다. 결과적으로 설계를 하지 않고 구현을 먼저 하고, 구현 하는 과정이나 운영 하는 과정에서 최적화 시킨다. 이것이 곧 최적의 설계로 나아가는 방향이 된다. (질문) 제가 제미니님이 말씀하신 '개념'과 '격벽'을 잘 이해한 것이 맞을까요? 실무에서 위 흐름대로 적용하면 제미니님이 강조하신 내용에 기반한 작업이 될 수 있을까요? 실무에서 실제로 말씀해주신 내용을 적용해보고 싶은데 구체적으로 어떤식으로 적용하면 될 지 몰라서 제가 이해한 내용을 바탕으로 작성을 해보았습니다. 틀린 부분이 있다면 피드백을 부탁드리고 싶습니다 :) 긴 글 읽어주셔서 감사합니다~

형님 안녕하십니까!2장 작전2 내용 중에, collected_logs에 모아진 모든 로그파일 내용을 Resource[]에 담고, 이를 flatFileItemReader로 읽기를 위임하는 부분이 있습니다. 아래는 그 중 Resource[] 배열에 해당 로그 내용을 담는 부분입니다. private Resource[] getResources(String date) { try { //String userHome = System.getProperty("user.home"); String userHome = "C:/Users/gyrbs/OneDrive/Desktop"; String location = "file:" + userHome + "/collected_logs/" + date + "/*.log"; //경로 직접 주입이 아닌 Resolver를 통한 url구성은 백슬래쉬가 아닌 /로 해야 인식 PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(); return resolver.getResources(location); } catch (IOException e) { throw new RuntimeException("Failed to resolve log files", e); } } 이에 대해서 gpt한테 몇가지를 물어보았는데, 먼저 배열에 읽어야할 내용을 담고 이를 filterReader로 읽는 과정이 Resource[] 배열에 읽어야할 모든 내용을 모두 저장하고, 이 저장한 내용을 reader가 받아서 청크지향처리라면 청크사이즈만큼 읽고 넘기고 아니면 지금과 같이 일괄적인 읽기를 진행하는 것으로 보였습니다. 그래서 만약에 읽어야할 내용이 매우 커지면 Resource[]라는 배열에 이 모든 내용을 넣기가 어려울 것이고, 강의에서 항상 강조해주시는 JVM무덤, 배치무덤이 되지않을까 하는 생각이 들었습니다. 그래서 이에 대한 방안을 gpt한테 한번 물어보았는데, public class StreamingMultiFileReader<T> extends AbstractItemStreamItemReader<T> { private Iterator<Path> fileIterator; private FlatFileItemReader<T> currentReader; private final Function<Path, FlatFileItemReader<T>> readerFactory; public StreamingMultiFileReader(Path dir, Function<Path, FlatFileItemReader<T>> readerFactory) throws IOException { this.fileIterator = Files.list(dir).iterator(); this.readerFactory = readerFactory; } @Override public T read() throws Exception { if (currentReader == null) { if (!fileIterator.hasNext()) { return null; // 모든 파일 처리 완료 } Path nextFile = fileIterator.next(); currentReader = readerFactory.apply(nextFile); currentReader.open(new ExecutionContext()); } T item = currentReader.read(); if (item == null) { // 파일 끝 currentReader.close(); currentReader = null; return read(); // 다음 파일로 넘어감 } return item; } }  이런 방법이 있다고 하는데(StreamingMultiFileReader로 deletegate 처리없이, 파일 하나하나씩 바로바로 처리해나가는 과정), 파일 하나하나씩 읽어들이면서 더이상의 파일이 없을때까지 순회하여 메모리부담은 없다고는 하였습니다. 혹시, 이 방법 말고도 청크지향처리를 이용해서 청크사이즈 만큼 파일, 혹은 파일 내부의 record를 읽고 넘기는, 그리고 이 과정을 모든 파일에 대해 순회하는 방식은 없을지 질문드려보고자 합니다! 실무에서 사용하는 방법이 궁금해서 질문드리게 되었습니다! 감사합니다.

안녕하십니까 형님!2강 작전2 : 분산 서버 로그 처형 작전 관련해서, 실무적으로 어떠한 방향으로 접근하는 것이 좋을지 의문이 생겨서 질문 드려봅니다!제가 윈도우 환경에서 실행하다보니, 자료에 기술된 cli를 윈도우 환경으로 바꾸는데 많은 비용을 소모하였습다.특히 이번 내용의 경우,단순 개행문자 및 OS간 인식문제를 넘어서, 명령어를 아예 윈도우 환경에 맞게 변경을 해야한다는 점에서 다소 힘이 많이 들었던 것 같습니다.뿐만 아니라, 윈도우 cmd 환경에서의 실행을 고려해서 cmd -c의 명령어를 추가해준다든지, 리눅스의 mkdir -p가 먹히지 않으므로 mkdir를 &&로 이어서 실행하게끔 한다든지..(이러다보니 collected_logs 폴더도 최초부터 존재하지 않아야 정상 실행이 가능한 환경적 제약사항까지 고려해야 하였습니다) 전체적으로 환경의 차이를 많이 느끼고 그만큼의 비용도 일전보다는 훨씬 많이 소모된 느낌이 있었던 내용이었습니다. //-p 옵션은 윈도우에서 안먹힘..따라서 collected_logs라는 디렉토리 생성(mkdir)은 처음부터 존재하지 않아야 한다. //SystemCommandTasklet -> 반드시 cli 명령어 작성 필요 @Bean @StepScope public SystemCommadTasklet mkdirTasklet( @Value("#{jobParameters['date']}") String date) throws IOException { SystemCommandTasklet tasklet = new SystemCommandTasklet(); // //tasklet.setWorkingDirectory(System.getProperty("user.home")); //실행환경은 batch 명령어 작성환경에 상관없이 무조건 cmd //경로직접주임은 반드시 백슬래쉬 tasklet.setWorkingDirectory("C:\\Users\\gyrbs\\OneDrive\\Desktop"); String collectedLogsPath = "collected_logs\\" + date; String processedLogsPath = "processed_logs\\" + date; //String collectedLogsPath = String.format("collected_logs\\%s", date); //String processedLogsPath = String.format("processed_logs\\%s", date); String command = String.format("mkdir %s && mkdir %s", collectedLogsPath, processedLogsPath); // //tasklet.setCommand("mkdir", "-p", collectedLogsPath, processedLogsPath); //tasklet.setCommand("cmd", "/c", "mkdir", collectedLogsPath); tasklet.setCommand("cmd", "/c", command); tasklet.setTimeout(3000); // 3초 타임아웃 return tasklet; }@Bean @StepScope public SystemCommandTasklet scpTasklet( @Value("#{jobParameters['date']}") String date) { SystemCommandTasklet tasklet = new SystemCommandTasklet(); //tasklet.setWorkingDirectory(System.getProperty("user.home")); String rootDirectory = "C:\\Users\\gyrbs\\OneDrive\\Desktop"; tasklet.setWorkingDirectory(rootDirectory); String collectedLogsPath = String.format("collected_logs\\%s", date); StringJoiner commandBuilder = new StringJoiner(" && "); for (String host : List.of("localhost", "loan", "pay")) { //String command = String.format("scp %s:~\\logs\\%s.log .%s\\%s.log", // host, date, processedLogsPath, host); String src = String.format("logs\\%s.log", date); String dest = String.format("%s\\%s.log", collectedLogsPath, host); commandBuilder.add(String.format("copy %s %s", src, dest)); } //String src = String.format("logs\\%s.log", date); //String dest = String.format("%s\\%s.log", collectedLogsPath, "localhost"); tasklet.setCommand("cmd", "/c", commandBuilder.toString()); tasklet.setTimeout(10000); //10초 타임아웃 return tasklet; } 이런 느낀점이 많다보니, 이번 내용을 진행하면서, SystemCommandTasklet을 실무적으로 어떻게 활용하면 좋을지 의문점이 생겼습니다. 첫번째는, 단순히 배치를 실행하는 환경이 리눅스라면, 리눅스 환경은 어차피 한동안 안고쳐질거니까, 윈도우라면 그것대로 윈도우 배치 환경은 거의 변경이 없겠지?라는 생각으로 단순히 SystemCommandTasklet으로 구성해야겠네!라고 생각하는게 맞는지 일단 의문이 들었습니다. 배치라는게 이러한 환경적 독립성을 유지하지 않고, 배치실행환경에 맞게 일단 구성하는게 맞을까요? 물론 이 내용이 SystemCommandTasklet을 배우는데 중점이 있을 수 있겠지만, 이번에 꽤 많은 소모를 느껴서 질문드리게 되었습니다! 두번째로, SystemCommandTasklet이 아닌 Tasklet을 사용하여 아래와 같이 시스템에 의존하지 않고 모든 시스템에 적용이 가능한 Java API버전으로 구성하였는데, 빌드 성공하긴 했습니다. //-p 옵션은 윈도우에서 안먹힘..따라서 collected_logs라는 디렉토리 생성(mkdir)은 처음부터 존재하지 않아야 한다. //tasklet -> return (con, ch) @Bean @StepScope public Tasklet mkdirTasklet( @Value("#{jobParameters['date']}") String date) throws IOException { return ((contribution, chunkContext) -> { Path desktop = Paths.get("C:\\Users\\gyrbs\\OneDrive\\Desktop"); Path collected = desktop.resolve("collected_logs").resolve(date); Path processed = desktop.resolve("processed_logs").resolve(date); Files.createDirectories(collected); Files.createDirectories(processed); return RepeatStatus.FINISHED; }); } 이렇게 처음부터 시스템에 상관없는(상관없이 구동이 가능한) 로직을 구현하는게 유지보수적으로도 맞지 않을까..하는 생각이 들었습니다. 형님께서는 실무적으로 이를 적용할때 어떠한 방향으로 구성하시는지, 제가 지금 의문이 드는게 맞는것인지.. 궁금해서 질문드려봅니다!(아니면 만약 SystemCommandTasklet과 같이 시스템에 의존적인 구현이 필요하다면, 이 경우는 환경적으로 바뀔 가능성이 현저히 적다던가..이러한 특수적인 상황적 조건이 있을때 사용하실까요?) 제약사항이 생각보다 커져서 배꼽이 더 커지는 상황이었기에, 형님께 여쭤보고자 하였습니다! 감사합니다!

안녕하세요 시간날 때 틈틈히 보다가 어느새 막바지에 다다랐네요! 타임베이스 정산 배치가 실패했을 때 궁금한점이 있습니다. 우선 현재는 시간 대별로 오전 1시, 4시, 9시로 배치가 나눠져있는데이 상황에서 강의에서도 설명하셨듯이 오전 1시 배치가 오전 4시 30분에 끝나서 오전 4시의 배치가 에러가 뱉는 상황에 대해 문제를 해결하는 방법들이 궁금합니다! 우선 제가 생각한 방법들은 다음과 같습니다.1. 이벤트 기반 이벤트 기반으로 각 단계가 완료되면 바로 다름 배치 단계로 넘어가는 방식입니다.하지만 이 방법은 이미 기존 인프라와 코드를 변경해야하고 정산 시간이 고정 된다는 요구사항이 있다고도 보여 현재 요구사항에는 적절하진 않은 것 같습니다.  2. 각 배치마다 전 단계 완료 여부 상태를 확인오전 4시, 오전 9시 배치가 이전 단계의 배치 중 실패한 배치 이력이 있는지 확인하는 방법입니다.현재 스케줄링 방식으로는 이를 위해 별도의 배치 기록 테이블을 만들어서 배치 이력 관리를 추가합니다.오전 4시, 오전 9시에 해당 정산 날짜에 대해 실패한 이전 배치 단계 이력이 있다면 성공할 때 까지 N번 재시도 합니다.정산의 즉시성이 필요하다면 N번 재시도 후 실패했을 때 해당 배치 단계를 에러 상태로 처리하고,에러 로깅과 알림을 전송합니다.다음 배치 단계는 정산 날짜에 해당하는 이전 배치 이력이 에러 상태로 남아 있다면 실행하지 않습니다. 현재 요구사항에서는 수동으로 처리할 부분은 최대한 제거하는 2번 방식을 사용할 수 있을 것 같습니다.제가 배치 관리에 대해 잘 이해하고 있는지 모르겠어서 생각한 방법에 대해서 재민님은 어떻게 생각하시는지 궁금합니다.! 항상 잘 보고 있습니다 감사합니다!  

@JoinColumn을 명시하는 경우가 있고 그렇지 않은 경우가 있는데 무슨 차이인가요?단순히 아래처럼 컬럼 명을 명시해주기 위해서 @JoinColumn이 사용되는 걸까요?@JoinColumn({ name: 'author_id' })

"4. 강의 PDF 자료 및 프로젝트"에서 프로젝트 소스는 있는데 강의PDF는 안 보이네요..어디에서 강의 PDF를 찾을 수 있을까요?

형 이거 CommandLineJobRunner를 통한 실행할 때 프로필도 줄 수 있어?

안녕하세요, 강사님. 취소 - 코드느끼기 수업의 5:00~ 부분부터'결제', '취소'의 스키마를 분리하여 레코드를 immutable하게 다루는 상황의 예시로 결제 취소 상황을 설명하셨는데 어떤 부분에서 유리한건지 모르겠습니다. 7일 전 주문을 30일 후에 취소함'취소'를 '결제'의 상태로 반영할 때'결제'의 상태를 '취소'상태로 변경 - 레코드 수정 시각 갱신취소된 '결제' 조회 시 레코드 수정 시각을 이용해야 함'취소'를 스키마로 관리할 때새로운 '취소' 레코드 추가제가 이해한 상황은 '취소된 결제를 결제 id 없이 취소 시각으로 조회해야한다'는 것입니다.취소된 결제를 결제 id 대신 취소 시각으로 찾는 경우는 어떤 상황인지, 조회를 위해 어느정도 취소시각의 범위를 특정할 수 있는 데이터가 존재할텐데 데이터가 결제 id와 분리되어 존재하는 이유가 무엇인가요?'취소'스키마가 따로 존재해서 결제 취소가 레코드로 쌓일 때, 취소 시각으로 찾는다면 무엇이 다른건지 모르겠습니다.'규모적으로 선택하라. 테이블이 적고 테이블 로우가 적고 접근 범위 자체를 줄일 수 있고, 이런 장점으로 보면 페이먼트 테이블을 만들어도 되는데요' 라고 말씀하신 부분도 모르겠습니다!수업 진행하시면서 1) 각 개념의 레코드가 자신의 영역 안의 맥락으로만 수정된다, 2) '결제'의 레코드는 많고, '취소'의 레코드는 적으므로 취소 일자로 조회하는 속도 차이가 난다고 하시는 것은 이해했습니다만 앞서서 예시로 들어주신 부분은 잘 모르겠네요. 감사합니다.

해당 강의는 강의자료가 있나요?

킬구형우리 매니저는 무슨 이유인지 mysql, postgres처럼 RDB를 무지무지 싫어해, 어떤 말을 해도 RDB는 절대 안된다고 하걸랑그런데 하필이면 Spring Batch가 RDB를 필요로 한단 말이지! 매일 밤마다 상용 서버의 로그 데이터를 분석하고 다른 데이터 소스로 보낼 정도로만 쓰려고 하는데, Spring Batch RDB로 H2 file mode나 sqllite로 Spring Batch를 돌려도 문제가 없을까 헝헝... 나 슬퍼