문제2번

안녕하세요. Choi님이런 부분을 한번에 다 완벽하게 답을 구하는 것은 쉽지 않습니다.많은 분들이 권장하는 방법은 우선 처음부터 끝까지 강의를 다 듣고, 그 다음에 한번 정도 복습하면서 정리하는 것입니다. (사실 어느정도 익숙해짐이 필요합니다.)도움이 되시길 바래요 🙂

SpringBoot 4.0.6 버전에서 PackageLogTracePostProcessor exception

안녕하세요. 마성호님도움을 드리고 싶지만 질문 내용만으로는 답변을 드리기 어렵습니다.실제 동작하는 전체 프로젝트를ZIP파일로 압축해서 구글 드라이브로 공유해서 링크를 남겨주세요.구글 드라이브 업로드 방법은 다음을 참고해주세요.https://bit.ly/3fX6ygx 주의: 업로드시 링크에 있는 권한 문제 꼭 확인해주세요추가로 다음 내용도 코멘트 부탁드립니다.1. 문제 영역을 실행할 수 있는 방법2. 문제가 어떻게 나타나는지에 대한 상세한 설명 (오류 화면, 오류 로그 포함)링크: 공식 서포터즈링크: 자주하는 질문감사합니다.

1:N 관계에서 중간테이블 (연관엔티티)

안녕하세요. shim9597님비즈니스 상황에 따라서 다른데요.질문하신 내용은 잘 생각해보면 이것은 1:N이 아니라 M:N이 맞습니다.왜나하면 하나의 예매는 여러 좌석을 예매할 수 있고, 하나의 좌석은 시간이 흐름에 따라 여러 예매에 의해서 예약되기 때문입니다. 따라서 이 경우 예매 - 예매좌석 - 좌석의 형태가 되어야 합니다.특히 예매와 좌석 만으로 1:N으로 구성하게 되면 문제가 있는데요.예를 들어 예매를 하신 이후에 예매를 취소하고, 다른 사람이 그 자리를 재예매 하는 경우 처음 예매한 좌석의 정보가 사라지는 문제가 있습니다.감사합니다.

공통코드 관련한 질문 드립니다.

안녕하세요. 쿵쿵뛰는꼬부기님애플리케이션에서 메타시스템DB에 직접 접근하기 보다는, 성능 저하 및 장애 확산(SPOF) 방지를 위해 '메타시스템(설계) → 서비스 DB(동기화) → 캐시(조회)' 파이프라인 구조를 권장합니다. 이때 실시간 변경이 필요하지 않다면 물론 ENUM을 사용하셔도 됩니다.슈퍼셋(Superset) 마스터 코드 전략을 권장합니다. 동일한 도메인(개념)을 공유한다면, 메타시스템 레벨에서 모든 상태를 포괄하는 표준 코드 하나만 정의하는 것입니다. 그렇지 않으면 향후 통합이 큰 어려움이 있을 거에요. 그런데 이름만 같을 뿐 개념과 관리 규칙이 완전히 독립된 서비스라면 당연히 둘을 분리해야 합니다.감사합니다.

제 3 정규형 vs BCNF 정규형 차이점?

안녕하세요. swdevelop24님생각하신 내용이 맞습니다 🙂감사합니다.

다음 강의는 언제쯤 나올까요?

klord님 기대해주셔서 감사합니다 🙂열심히 준비중인데, 아무래도 가장 난이도가 있는 강의라서 그런지 준비하는데 시간이 많이 걸리네요.대략 2달 정도 예상하고 있습니다^^!기대해주셔서 고맙습니다!

코드 자료

안녕하세요. 여비님이번 강의는 코드를 처음부터 따라하면서 이해하는 것을 목표로 하기 때문에 의도적으로 코드를 제공하지 않습니다 🙂화이팅!

간단한 오타 제보입니다.

최형석님 감사합니다^^!다음 버전에 패치할게요!

실제 FK제약조건을 설정하지 않는이유

안녕하세요. 오승환님모든 곳에서 다 FK를 빼고 사용하는 것은 아니고, 다음과 같은 이유로 FK를 빼는 경우들이 있습니다. 1. 운영이 불편함배치, 데이터 이관, 테스트 셋업할 때 INSERT/DELETE 순서 맞춰야 하고, 조금만 꼬이면 제약 위반으로 실패합니다. FK 끄고 작업하는 일이 많아집니다.2. 스키마 변경이 무거워짐부모 테이블 구조 바꾸려면 자식 FK 드롭 → 작업 → 재생성하는 과정이 필요합니다.3. 확장성 — DB 분리 대비MSA로 쪼개면 DB 레벨 FK는 못 씁니다. 어차피 애플리케이션이 정합성을 책임져야 하니, 처음부터 그 구조로 갑니다. 하지만 트레이드오프를 고려해야 합니다.FK를 빼면 운영 유연성과 확장성을 얻고, 대신 정합성 책임이 애플리케이션으로 넘어옵니다. 모든 검증 로직을 명확하게 애플리케이션 로직에서 책임져야 하는데, 시간이 지날수록 보통 잘 오염되고, 이상한 중복 데이터나, 자식이 반드시 필요한데 없는 경우가 발생합니다. 이 문제 때문에 또 방어 코드를 추가해야 하는 경우들도 생깁니다.제가 추천하는 방법은 '기본적으로는 FK를 사용해 데이터 무결성을 보호하되, 시스템의 규모와 도메인 특성에 맞춰 유연하게 제거하는 것'입니다.실무적인 관점에서 다음과 같이 접근해 보시길 권장합니다.정합성이 최우선인 코어 도메인 (결제, 정산 등): 데이터가 틀어질 때의 비즈니스 리스크가 매우 크므로 DB 레벨의 FK 제약조건을 굳건히 걸어두고 2중, 3중으로 보호하는 것이 좋습니다.대규모 트래픽 및 유연성이 필요한 도메인: 잦은 스키마 변경과 성능 최적화가 중요하거나, 향후 MSA 분리가 예상되는 서비스라면 FK를 물리적으로 제거하여 운영의 유연성을 확보합니다.논리적 관계 유지 및 보정 배치: DB에서 물리적인 제약조건CONSTRAINT)은 제거하더라도, ERD 상의 논리적 연관관계는 명확히 남겨두어야 합니다. JPA 같은 ORM을 사용한다면 애플리케이션 레벨에서 연관관계를 철저히 매핑하여 검증하고, 주기적으로 백그라운드 배치(Batch)를 돌려 고아 데이터나 정합성이 깨진 데이터를 모니터링하고 정리하는 안전장치를 함께 마련하는 것이 좋습니다.결국 서비스 규모가 커지고 아키텍처가 복잡해질수록 무결성 유지의 책임은 DB에서 애플리케이션으로 넘어오게 됩니다. 현재 프로젝트의 단계, 트래픽 규모, 그리고 팀의 방어 코드 작성 역량을 종합적으로 고려하여 적절한 트레이드오프를 선택하시길 바랍니다.감사합니다.

RepositoryTest의 패키지 위치가 domain인 이유

안녕하세요. dev.rudevico님오타가 맞습니다 🙂다음에 한번 정리해야겠네요.감사합니다^^!