H2데이터베이스 파일 생성

안녕하세요. 김주현님해당 선택은 사실 URL을 편리하게 적도록 도와주는 템플릿 기능입니다.URL에 적는 내용이 중요하기 때문에 해당 내용은 무시하셔도 괜찮습니다 🙂감사합니다.

히스토리 관련 질문

안녕하세요. 김재연님 🙂강의를 더 진행해보시면 생각하신 구조로 진행이 될거에요.추가로 각각의 사용 상황을 말씀드리면 다음과 같습니다. 히스토리를 애플리케이션 단(코드)에서 트랜잭션으로 직접 INSERT 하고, 변경 사유가 단순 감사(Audit) 및 이력 추적용이라면:질문자님 생각대로 히스토리 테이블에만 사유 컬럼을 두는 것이 베스트 프랙티스입니다. 원본 테이블을 깔끔하게 유지하세요.히스토리를 DB 트리거로 자동 적재해야 하거나, 현재 상태의 변경 사유를 메인 화면에서 JOIN 없이 빠르게 읽어야 한다면:원본 테이블에도 사유 컬럼을 추가하는 것을 고려하셔야 합니다.감사합니다 🙂

섹션 2 퀴즈 9번

안녕하세요 wxd8339님정확하게는 생각하신 내용이 맞습니다 🙂다만 문제의 의도를 보면 equals() 메서드 자체가 논리적 동등성을 위해서 만들어진 것이기 때문에 C로 보는 것이 맞습니다.감사합니다.

진짜 강의 듣는거 너무 고문

안녕하세요. 현석오님데이터 모델링 파트가 원래 많이 건조하고 추상적이라 힘들 수 있습니다. 빨리 핵심만 보고 넘어가고 싶은 그 답답한 마음, 저도 공부할 때 겪어봐서 많이 공감합니다.하지만 너무 마음이 급할 때는 오히려 거북이 같은 마음으로 한 걸음씩 천천히 나아가는 게 결국 가장 빠른 길이더라고요. 특히 식별/비식별 관계 같은 DB의 뼈대가 되는 부분은 대충 넘어가면 나중에 실무에서 복잡한 데이터를 다룰 때 정말 크게 고생할 수 있거든요.눈으로만 훑고 지나가기보다는, 조금 귀찮고 진도가 안 나가더라도 예제를 하나하나 직접 따라 해보고 '여기선 왜 이렇게 설계했을까?' 치열하게 고민하면서 진행해 보시는 걸 정말 추천해 드립니다. 지금 당장은 느리게 느껴지시겠지만, 이때 천천히 그리고 깊게 고민해 둔 시간들이 나중에 실무에서 석오님의 가장 든든한 무기가 될 거예요. 응원합니다 🙂

강의 자료에 사소한 오타가 있습니다.

i2mi님 고맙습니다^^!다음 버전에 패치할게요.

오탈자 - @Transactional

장태근님 감사합니다^^!다음 버전에 패치할게요!

RequestHandler 버전 간 process() 파라미터 차이 질문

안녕하세요. sjahn님둘다 필요한 방법입니다 🙂진행중에 각각 필요한 방식이 달라지기 때문에 중간에 변화가 되었습니다. 1. 멤버 변수 방식 (상태를 가지는 객체 - Stateful)적절한 상황: 객체가 고유한 데이터(상태)를 스스로 관리하고, 그 데이터의 변화를 추적해야 할 때. 2. 파라미터 전달 방식 (상태가 없는 객체 - Stateless)적절한 상황: 객체가 스스로 데이터를 기억할 필요 없이, 외부에서 재료를 받아 가공이나 흐름 제어 같은 '행위(로직)'만 전담할 때. 감사합니다.

교재 p.31 실행순서 오류?

안녕하세요. swdevelop24님생각하신 내용이 맞습니다 🙂데이터베이스 SQL의 실행 순서는 논리적 실행 순서와 물리적 실행 순서가 있습니다.논리적 실행 순서는 사람이 이해하기 쉬운 순서이고, 물리적 실행 순서는 데이터베이스가 내부에서 최적화하는 실제 순서입니다.처음 데이터베이스를 접하는 분들 입장에서는 내부 최적화 구조까지 이해하면 데이터베이스가 정말 어려워지기 때문에 지금은 사람이 이해하기 쉬운 논리적인 순서를 말씀드린거에요^^이후에 기본편에 들어가면 데이터베이스가 내부 구조까지 모두 이해하실 수 있을거에요 🙂감사합니다.

통계 데이터 수정 질문

안녕하세요. learnlearn님비즈니스 상황을 자세히는 모르겠지만, 특정 유저와 날짜 단위로 배치가 이루어지고, 해당 배치가 크게 부담이 되는 상황이 아니라면, 수정한 사용자와 수정 일자만 모아두고, 해당 사용자의 해당 수정 일자의 배치만 멱등하게 돌아가도록 하면 깔끔하게 진행될 것 같아요.실시간 증분은 속도는 빠를 수 있지만 멱등성이 깨질 수 있기 때문에 더 많은 고민이 필요합니다.감사합니다.

공통 코드에서 Redis Pub/Sub은 최근 실무에서 쓰이진 않나요?

안녕하세요. kekim님AI 인턴이 잘 답변해주었는데요. 조금 더 보충하자면이 부분은 실무에서 겪고 있는 상황에 따라 다릅니다.비즈니스 로직상 정확한 갱신이 너무 중요하다면 Redis Pub/Sub은 고민하신 것 처럼 리스크가 있습니다.다만 현재 팀에서 Redis를 잘 사용하고 있고, 비즈니스 로직상 만약에 갱신에 일부 실패해도 허용 가능한 범위의 리스크라면 Redis Pub/Sub을 사용해도 괜찮습니다.감사합니다.