안녕하세요. 강의 잘 수강하고 있습니다. SubStack 1년 무료 제공 링크를 통해 신청했는데,신청 처리 되었는지 확인 부탁 드립니다. 

안녕하세요, 강의 잘 듣고 있습니다 감사합니다! SubStack 1년 무료 제공 관련해서 https://forms.gle/diKHUhvUe61JwzXF7 링크를 통해 신청했는데, 신청 정상적으로 되었는지 확인 부탁드립니다! 감사합니다!

안녕하세요 영한강사님! 좋은 강의 너무 잘들었습니다! 강의에는 없는 내용이긴한데요! 실무에서는 실제 FK제약조건을 설정하지 않더라구요. 선배님들은 확장성때문이라고 말씀해주시는데 이것말고도 다른 이유가 있는지 궁금합니다!

마지막에 professor_name을 pk로 두고 그에 따라 1:1이기때문에 과목명을 그냥 컬럼으로 두셨는데 그러면 그 과목명이 만약에 바뀐다면 (데이터베이스 -> DB) 그렇다면 데이터베이스 수업을 하는 모든 교수님의 컬럼을 바꾸어야하니 갱신이상이 일어나는것 아닌가요?이런 경우는 어떤 정규형을 위반한건지 궁금합니다.

안녕하세요 조영호님, 강의 복습하며 설계의 깊이를 더해가고 있는 수강생입니다. 8~9장을 통해 상/하위 모듈의 패키지 배치 원리를 배우며 실무 적용에 대해 고민이 생겨 질문 남깁니다. 그동안 실무에서 레이어드 아키텍처를 주로 사용하며 서비스와 도메인 로직을 구분해 왔는데, 복습하다보니 그간 해왔던 물리적인 패키지 분리(인터페이스와 구현의 분리 등)를 엄격하게 적용하는 것이 자칫 오버 엔지니어링이 아니었을까 하는 생각이 들었습니다.# 프로젝트 패키지 구조 예시 Project - ServiceInterface - ServiceImplement - RepositoryInterface - RepositoryImplement - Controller - Model  최근에는 의식해서 도메인 모델을 만들어 보는데, 기존 레이어드 아키텍처의 패키지 구조 내에서는 '도메인의 응집도'와 '레이어의 규칙'이 충돌하는 지점이 생겨 배치가 모호해지곤 합니다. 이에 두 가지 질문을 드리고 싶습니다.1. 단순히 레이어드 아키텍처로 감당하기 힘들어지는, 즉 '도메인 중심의 패키지 구조'로 변화해야 하는 구체적인 징후나 시점이 있을까요?2. 모든 모듈에 엄격한 패키지 분리를 적용하기에는 비용이 부담된다고 생각되는데, 마치 절차지향과 객체지향 중 하나를 선택하듯, 패키지 수준의 격리를 우선적으로 적용하기 좋은 도메인 특성이 있을까요? (예: 정책 복잡도가 높아 사이드 이펙트가 빈번한 곳, 혹은 외부 인프라 변경에 민감한 핵심 도메인 등)  최근에는 조영호님의 도서/강의 통해 배운 내용을 의식하면서 실무에 적용해보는데, 예전보다 일 하는게 즐거워진거 같습니다. 미리 답변 감사드립니다. 좋은 하루 되세요. 🙇🏻  

안녕하세요! 연관 엔티티의 네이밍 기준(연결 강조 vs 의미 있는 이름)에 대한 강의를 듣고 고민이 생겨 질문드립니다. 강사님의 조언대로 처음에는 '의미 있는 이름'을 우선적으로 부여하고자 했습니다. 하지만 실제 설계를 진행하다 보니 다음과 같은 딜레마를 겪고 있습니다. 1. 직관성 저하 및 매핑 테이블 식별의 어려움명확한 의미가 떠오르는 것만 의미형으로 짓고, 나머지는 연결 강조형(A_B)으로 설계했더니, 전체 ERD를 볼 때 어떤 테이블이 독립 엔티티인지, 어떤 테이블이 단순히 N:M 관계를 해소하기 위한 매핑 테이블인지 한눈에 파악하기가 어려워졌습니다. 규칙이 혼재되다 보니 오히려 일관성이 무너지는 느낌을 받았습니다. 2. 다중 다대다(N:M) 관계에서의 한계그렇다고 매핑 테이블의 일관성을 위해 모두 '연결 강조형(A_B)'으로 통일하자니, 두 엔티티 사이에 여러 개의 M:N 관계가 존재할 때 문제가 발생했습니다. 예를 들어, User와 Store 사이에 '찜하기', '방문 내역' 등 여러 맥락의 관계가 존재할 경우, 단순한 user_store라는 이름만으로는 이 관계들의 성격을 전혀 대변할 수 없었습니다. 보통 실무에서 이러한 상황일 때, 일관성(매핑 테이블임을 명확히 인지)과 의미(어떤 맥락의 관계인지 표현)를 모두 충족시키기 위해 주로 어떤 네이밍 패턴이나 타협점을 사용하시는지 실무 노하우가 궁금합니다!

안녕하세요, 선생님!6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다.데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지  일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다.  제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.   

안녕하세요. 히스토리 테이블 관련해서 질문이 있습니다. 원본테이블에 업데이트 이유를 트랙킹할 필요가 있으면 변경 사유 컬럼들을 추가하라고 말씀주셨는데  생성, 수정, 삭제시 모두 히스토리 테이블에 스냅샷형태로 저장한다면 변경 사유 컬럼들은 히스토리 테이블에만 있는게 좋지 않을까 싶어서 질문드립니다.

대충 빨리 듣고 필요한것만 정리 하고 넘어가고 싶은데 어렵고 지루하고 졸리고

안녕하세요, 요즘 이직 준비하면서 CS 인사이드나 좀 얻고자 해당 강의를 무료로 수강 중인데요. 우선 영상 만드시는데 수고하신 것 같습니다만 이해가 안되는 부분들(다형성)이 있어서 문의드립니다. 2강 '객체지향은 어떻게 동작하는가?' 6:08 해당 주제명과 코드는 추상화 라고 해야 적합할 듯한데요. OCP는 추상화에 관련 있기도 하고요 6:26 다형성의 핵심은 부모타입으로 다루는 것(구현이 아닌 추상에 의존한다) 이 말씀이 무슨 말씀인지 이해가 잘 안되는데, 공부하셨던 자료 출처가 있을까요? 결론적으로 문의를 요약하면 다형성 개념을 오버로딩/오버라이딩 개념보단 추상화 개념으로 보는 것 같은 데 다형성과 추상화과 어떤 관련이 있는 지 궁금하며 공부하신 자료 출처를 남겨 놔주시면 다른 이들도 함께 공부하는 기회가 될 것 같습니다 :))

자료 한번에 다운로드 받을 수 있도록 압축해서 하나로 묶어주세요. 일일이 다운받는게 번거롭네요.

안녕하세요, 좋은 강의 만들어주셔서 정말 감사합니다!!이번에 신규 기능을 추가하면서 통계 데이터도 필요한 상황인데 통계 데이터에 사용되는 원본 데이터가 수정되는 케이스는 어떻게 설계하는게 좋을지 조언을 구하고자 질문드립니다.통계 데이터는 유저가 조회하고, 데이터 조회 기간은 최근 7일/최근 한달/과거 한달(사용자 조정 가능)로 조정이 가능하고, 한 화면에 4가지 유형의 통계 데이터를 제공해야 해서 이를 위해 일별 통계 테이블을 사용하려고 했는데요.그런데 원본 데이터가 언제든 수정되거나 추가될 수 있는 상황입니다.그래서 수정한 사용자와 수정 일자를 따로 모아 배치를 돌리는 방향이 생각났는데 이렇게 설계해본 경험이 없어,우선은 실시간 증분 업데이트를 진행하고 데이터 정확성이 필요해지는 상황이 필요하다면 그때 위와 같은 배치를 돌리는게 나을지 또는 다른 방향이 있을지 궁금하여 질문드립니다.정산 데이터는 아니기 때문에 멱등성이 깨질 수 있는 상황은 감안하고, 기획 요구사항인 실시간성을 반영하는게 좋을지도 고민이 되어 질문드립니다!

28강 sql 파일 어딨나여?

안녕하세요 미국 달팽이님! 강의 잘 듣고 있습니다.https://inf.run/JxEdX에서 안내주신 구글 폼 링크로 수강 닉네임과 substack 이메일을 제출했는데, 혹시 제가 입력한 정보가 잘못됐을까요? 확인 한번 부탁드립니다.!

안녕하세요3-2. 조합 메서드로 리팩터링하기 의 11분 08초에 예제 코드 보면서 리팩터링을 해보고 있는데 예외가 발생했습니다. java.lang.ArrayIndexOutOfBoundsException: Index 6 out of bounds for length 6 moveNorth() 실행시 y가 -1이 입력되는데else 부분에 y를 한번 더 더해주다보니 문제가 발생한것으로 보입니다. private void moveNorth() { tryMove(0, -1); } // before private void tryMove(int incX, int incY) { if(y + incY < 0 || y + incY >= height || x + incX >= width || x + incX < 0 || roomAt(x + incX, y + incY) == null) { showBlocked(); } else { this.x += incX; this.y += y + incY; // 💩 y = -1일때 -1 + (-1)이 됨 showRoom(); } } // after private void tryMove(int incX, int incY) { if(y + incY < 0 || y + incY >= height || x + incX >= width || x + incX < 0 || roomAt(x + incX, y + incY) == null) { showBlocked(); } else { this.x += incX; this.y += incY; // ✅ showRoom(); } }  

2NF를 충족하기 위한 조건은 다음과 같은 것으로 알고 있습니다.제1 정규형을 만족하고,모든 컬럼이 후보 키 전체에 완전 함수 종속되어야 한다. 예를 들어 수강 테이블의 컬럼이 다음과 같다고 할 때,id: PK [대리 키]student_id: UK1 [자연 키]course_id: UK1 [자연 키]student_name [일반 컬럼]후보 키:id [기본 키 - 단일 후보 키](student_id, course_id) [대체 키 - 복합 후보 키] (student_id, course_id)는 복합 후보 키이고,student_id -> student_name (부분 함수 종속)이므로 2NF에 위배되지 않나요?따라서 대리 키만 써도 2NF에 위배되는 일이 발생할 수 있다고 생각합니다. 아니면, 실무에서는 2NF의 정의를 기본 키에만 한정하여 2NF를 만족하는 것으로 보나요?   

Redis Pub/Sub 구독을 통해 Redis 갱신 시 Sub로 구독 중인 각 서버에 캐시 무효화 및 강제 갱신 시키는 구조는 잘 안쓰이나요?이 방법도 네트워크 순단 시 fire and forget, 구현 복잡도가 높음 등의 문제가 있긴한데 실무에서는 Pub/Sub을 잘 안쓰는지 궁금합니다.

안녕하세요 단건데이터(ex: 로그) 처리의 경우에는 크게 고민하지 않고 MERGE를 사용하여 처리하고 있습니다. 하지만 10~20건 이상의 데이터셋이 들어오는 경우에는 어떤 방식으로 처리하는 것이 더 적절한지 고민이 되어 질문드립니다. 데이터 DELETE -> INSERT 2번의 쿼리 수행(또는 BEGIN으로 1번에 수행)  데이터 STATE (I, U, D 등)를 활용하는 방식 화면에서 데이터에 INSERT / UPDATE / DELETE 상태값을 기반으로 서버에서 DELETE 1회, INSERT 1회, UPDATE N회를 수행실무에서는 작업 공수 문제로 1번 방식(DELETE -> INSERT)을 선택하는 경우가 많았습니다. 다만 이 방법을 사용하면서 DELETE로 인해 발생하는 DB 블록 낭비기존 데이터의 CREATE_DATE가 유지되지 않아 UPDATE_DATE와 의미 차이가 사라지는 문제데이터 관리, 유지보수, 성능 측면에서 어떤 방식이 더 바람직한 선택인지 궁금합니다.

안녕하세요 영한님!"8. 상속 관계 설계" 강의에서, 상품 테이블을 예시로 들어, 슈퍼타입-서브타입 모델링을 설명해주셨는데요! 만약에 서브타입이 다른 테이블과 관계를 맺게 된다면, 이 케이스에도 슈퍼타입-서브타입 모델링을 적용하는게 괜찮을지 궁금하여 질문을 드립니다! 예를 들어, 신고 내역을 저장하는 테이블을 모델링하는 상황에서, 회원 신고/게시글 신고/댓글 신고/그룹 신고 이렇게 나뉜다면 슈퍼타입-서브타입 상속 전략을 사용해도 괜찮은지 궁금합니다.

안녕하세요! 강의를 듣다보니 TTL 캐싱을 사용할 때에도 오류가능성이 존재하지 않나 싶어 질문 남깁니다. TTL을 1분이라 가정했을 때 TTL이 지나기 전에 DB의 값이 바뀌고, 그 이후 TTL이 지나기 전에 캐싱된 값을 사용하게 된다면 DB에 있는 값과 캐싱되어있는 값에는 차이가 존재하지 않나요? 이에 대해선 어떻게 구현되어있는지 궁금합니다