저희는 용어 사전을 DataGrip 에서 table 마다 Comment 를 할수있어서Table 에 Comment 를 달고 Column 에다가도 Comment 를 달아서 설명을 붙여서 사용하고 있습니다 . 이런식으로 사용하고 있는데 보통 어떻게 사용하시나요 ??

주문 결제 배송을 하나의 테이블로 두지 않고 분리를 시켰을때 어떤 장점이 있나요 ??  

강의에서 배운 모델링을 바탕으로 프로젝트를 진행하려고 하는데 궁금한점이 생겼습니다. 1:1 관계인 orders 테이블과 delivery, pay 테이블의 관계에서 외래 키를 보조 테이블에 두었는데, jpa를 이용한 애플리케이션 코드에서는 일대일 관계에서 대상테이블에 외래 키를 두었을때 즉시로딩으로 N+1 문제가 발생할 수 있어서 orders엔티티에 외래 키를 두었습니다. 이때 db와 애플리케이션 간에 테이블 구조가 불일치하기 때문에 오류가 발생할 것으로 예상됩니다. 이 경우 주문과 배송, 결제 정보가 같이 생성된다고 보고 외래 키 위치를 주 테이블에 두어야할까요? 아니면 애플리케이션 코드에서 즉시로딩 문제를 해결해야할까요?

안녕하세요, 좋은 강의 감사드립니다. 현재 해외 취업을 목표로 시스템 디자인 인터뷰를 준비 중인 수강생입니다. 낯선 문제를 만났을 때 하이레벨 디자인에서 딥다이브로 넘어가는 과정에 어려움이 있어 조언을 구하고자 합니다. 강의 시퀀스인 [요구사항 정의 -> 하이레벨 디자인 -> 딥다이브(API, 모델링 등) -> 리뷰]를 준수하며 연습하고 있으나, 익숙하지 않은 도메인에서는 하이레벨 디자인 단계에서 예외 케이스나 컴포넌트를 제대로 커버하지 못하는 경우가 많습니다. 그러다 보니 딥다이브(c)를 진행하는 도중에 설계 오류를 발견하고 다시 하이레벨(b)을 번복하게 됩니다. 처음 보는 문제에서도 하이레벨 디자인을 탄탄하게 잡고 갈 수 있는 접근법이나, 이러한 번복 플로우를 줄일 수 있는 인터뷰 팁이 있을지 여쭤보고 싶습니다.

안녕하세요 ^^ 아주 작지만 소소한 정오표 전달드립니다. 7. 논리적 모델링3 - 일대일, 다대다 관계49페이지AS-IS우리가 실제 '수강신청 시스템'을로 만든다고TO-BE우리가 실제로 '수강신청 시스템'을 만든다고 마우스 드래그 하는 중에 바뀌는 부분 확인했습니다! 항상 감사합니다!

안녕하세요 선생님,실제 필드에선 클라이언트의 요구 사항이 명확하지 않고, 기획자가 없으며, 개발자가 대부분의 일을 다 해내야 하는 경우가 있는데,클라이언트(대표님 또는 상사)와 소통, 기획서 작성, 설계, 개발까지 혼자 하게 될 때 현명하게 대처하는 방법은 뭐가 있을까요?큰 기업은 각자의 업무에 집중할 수 있겠지만, 작은 기업은 그게 쉽지 않은 걸 알고 있습니다클라이언트와 소통, 화면 기획 및 요구 사항 작성등은 어떤식으로 공부해야할까요?

orders product 중간 테이블 order_product 에서orders -> order_product 참여도 및 카디널리티가O< 로 되어있는데주문은 하나의 주문 상품은 꼭 포함해야하니까 -|< 가 맞지 않나요? 질문 남깁니다!

안녕하세요. 공통 코드와 계층 구조 관련해서 질문이 있어 질문 드립니다. 이전에 경험했던 프로젝트 보면 공통 코드와 계층 구조 테이블을 다 합친 일명 '만능 코드 테이블' 에 모두 넣고 사용하는 방식도 사용했는데 이번 공통 코드(자연키, 복합키) 강의와, 계층 구조의 강의를 들으며 시야가 또 달라지네요.예를 들면 주문 상태 코드와, 상품 코드를 하나의 테이블의 대체키, 외래키를 적용해서 사용했었네요. 혹시 '만능 코드 테이블'의 경우는 추후 유지보수와 개발 편의 관점에서 개선해야하는 부분이 맞겠지요?만약에 개선하게 된다면, 어떤 기준으로 나누면 될지. 설계적 관점에 대해 혜안을 듣고 싶습니다. 예를 들면, 공통 코드 테이블 2개와, 계층 테이블 이렇게 두고 계층의 가능성으로 보통 나누는지 궁금하고, 추가로 도메인 성격까지 고려해서 테이블을 또 쪼개는지 등이 궁금합니다. 그리고 CS 팀에서 고객 문의 사항에 문의 유형을 최초 상품, 주문, 배송 이런식으로 공통 코드에 넣어서 사용하고 있었는데, 갑자기 정책이 바뀌면서 주문 하위에 주문 오류, 주문 취소 등 하위 개념이 생기면 계층 테이블로 옮겨야 할 거 같은데 이런 경우는 애초에 기획당시에 개발자가 확장 가능성에 대해 고민을 하고 공통 테이블로 넣었으면 안되는 것인지에 대한 부분도 궁금하네요. 매번 질높은 강의로 도움주셔서 감사합니다!

자동차 협력사에서 주로 A-SPICE를 진행하는 것으로 이해되는데이 프로세스 중에 OEM, 그 중 연구소 품질직무에서 하는 역할이 뭔지 알 수 있을까요?아니면 ASPICE V 모델에서 OEM이 개입하는 부분이라던가,,,,,

안녕하세요, 유저 테이블과 구독 테이블 설계 중 해결하기 까다로운 지점이 생겨 질문드립니다.*현재 상황을 보다 이해하시는데 문제가 없으시기 위해 ai로 질문을 정리한점 먼저 말씀드립니다.1. 현재 상황 및 서비스 정책유저 테이블:id(PK), email(UK) / 탈퇴 시 소프트 삭제, 개인정보 보호를 위해 이메일 마스킹 필수.구독 테이블: 현재 활성화된 구독 정보 딱 1건만 관리 (이력은 별도 테이블 존재).서비스 정책: 탈퇴 후 동일 이메일로 재가입 시, 기존 로우 복구가 아니라 새로운 로우로 Insert 됩니다. 단, 재가입 시 과거 구독 정보는 그대로 이어받아야 합니다.2. 제가 고민해 본 방법들과 예상되는 문제점생각한 방법 1) 구독 테이블이 유저 PK(id)를 외래키로 바라보게 한다.예상 문제: 재가입 시 유저 테이블에 새 로우가 Insert 되면서 새로운 PK를 발급받기 때문에, 과거 PK를 바라보고 있던 구독 테이블과 연결 고리가 끊어집니다.생각한 방법 2) 유저 테이블에 '이메일 해시(유니크X)'를 두고, 구독 테이블과 해시값으로 매핑한다.예상 문제: 해시는 개인정보가 아니므로 탈퇴 후에도 유저 테이블에 남겨둘 수 있어 재가입 매칭은 가능합니다. 하지만 유저가 중간에 이메일을 변경하는 경우, 유저 테이블의 이메일 해시뿐만 아니라 구독 테이블 및 구독 이력 테이블의 해시값까지 전부 동시 UPDATE 쳐야 하는 번거로움이 생깁니다.3. 질문 요약개인정보 보호를 위해 유저 테이블의 이메일 원본은 마스킹하면서도, 재가입 시 동일인임을 식별해 과거 구독 정보를 매칭해 주어야 합니다. 여기에 유저의 이메일 변경 가능성까지 고려해야 하는 상황입니다.이 경우 구독 테이블의 매핑 키 체계를 어떻게 잡는 것이 가장 깔끔하고 현명한 DB 설계 원칙일까요? 실무에서 이런 케이스를 해결하는 정석적인 아키텍처 가이드가 궁금합니다!

자연키vs대리키 강의를 보면 대리키를 사용하는게 안정성,유연성에 있어 많은 장점이 있어 대부분 대리키를 사용한다고 하셨는대,다음과 같은 케이스에도 대리키를 쓰는게 좋을지 궁금합니다. (뒤에 강의에 나올수도 있지만 현시점 궁금해서 질문드립니다.)1. 조인테이블의 경우 a,b테이블의 pk인 대리키를 이용해 복합키를 만들어서 pk로 쓰면 될지, 아니면 그것 역시 따로 대리키를 만들어야 할지 궁금합니다.2. 정말 단순한 enum 형태의 테이블일 경우, 예를 들어 유저상태값을 표현하기위해 정상,휴면,탈퇴 등을 기록하는 테이블의 경우 자연키, 대리키 어떤거를 써야할지 궁금합니다. 제가 경험한 바로는 enum 형태의 간단한 테이블조차 대리키를 사용하니 유저 테이블을 조회할때 간단한 상태값조차 조인을 해서 봐야하니 불편하더라고요.감사합니다.

안녕하세요 우선 값진 강의 만들어주셔서 감사드립니다. 취준을 하며 개인 프로젝트를 진행 중인데, 고민 해오던 부분들에 많은 도움이 되었습니다. 강의를 완강하고, 학습한 내용들을 바탕으로 이전에 진행했던 프로젝트의 DB를 재검토하고 재설계 해보고 있습니다.구글링, 해당 게시판에 올라온 이전 질문들 참고하고 ai와 대화를 하고도 완전하게 확신이 서지 않는 부분이 있어서 질문드립니다.우선 제가 만들고 있는 서비스는 "좌석이 있는 공연 예매 시스템" 입니다.공연 데이터 생성시 해당 공연의 좌석들이 함께 생성됩니다. 즉 특정 공연의 특정 좌석들이 고유하게 생성됩니다.그리고 사용자는 좌석을 다중 선택하여 선점하고 예매할 수 있습니다.(예매 - 좌석) 관계는 (1:N) 입니다.그래서 기존 DB 에서는 N 쪽인 좌석이 예매 id 를 fk 로 들고 있는 간단한 형태로 진행하였습니다. 그런데 강의 중 다대다(M:N) 관계 부분에서 연결 테이블의 본질이 관계 자체를 하나의 독립된 데이터로 보고, 그것을 테이블로 모델링 하는 것 이라는 내용을 접하고,비록 1:N 관계이지만, 예매 - 좌석 관계가 엔티티로 승격될만 한가에 대한 고민을 했습니다. (강의에서 예시로 사용된 주문 - 주문상품 - 상품 을 보며, 좌석을 수량이 단 하나뿐인 상품이라고 생각한다면 예매 - 예매좌석 - 좌석 형태가 비슷하다고 생각했습니다.) 이유가 충분하다면 실무에서도 N:M 관계에서 뿐만 아니라 1:N 관계에서도 중간테이블 (연관엔티티)를 두는 설계를 실제로 하는지, 현재 상황에서도 (질문이 너무 길어지고 복잡해질까봐 제가 판단한 이유들을 설명드리진 않았지만) 연관관계 엔티티를 두는 것이 타당한 판단일지 고견 여쭈어봅니다. 긴 질문 읽어주셔서 감사합니다!

안녕하세요, 공통코드 관련하여 코드그룹, 코드상세 테이블 설계 강의 잘 들었습니다.관련하여 2가지 질문이 있습니다!1. 혹시 사내에 dataware라는 메타시스템을 사용할 경우에는 어떤 식으로 운영을 하는지 궁금합니다. 전 회사에서는 메타시스템은 단순 정의 용도로 사용하고, 모든 코드값은 enum으로 사용을 했었는데요~강의 내용에 있는 것처럼 값이 바뀔 때마다 계속 재배포 작업을 해야 하긴 했지만, 그 외에 특별한 이슈는 없었던 것 같습니다. (배치성 프로젝트라 빠른 대응이 필요하지 않았음) 현 회사에서는 아직 정해진 정책은 없지만, 메타DB를 어플리케이션에서 접근할 수 있도록 하는 방법은 어떨지도 고민하고 있습니다.그래서 일반적으로는 메타시스템, 공통코드 테이블, enum을 어떤 식으로 mix하여 사용하는지 궁금합니다. 추가로 고유한 컬럼 인식을 위해 최대한 유니크한 컬럼명을 사용하고 있는데요~예를 들어, 사용자로그인상태코드라는 컬럼이 있더라도 사이트에 따라 아래처럼 분리하는 경우가 존재합니다.A사이트사용자로그인상태코드B사이트사용자로그인상태코드이 경우 같은 아래처럼 코드값을 다르게 정의할 경우 현실적으로 체크하는 것이 좀 어려운 것 같습니다. A사이트의 경우 0:정상, 1:잠금, 2:정지, 3:휴면, 4:탈퇴 B사이트의 경우 0:정상, 1:잠금, 2:탈퇴, 3:휴면 (B사이트는 정지 상태가 없음)같은 의미의 코드일 경우 같은 코드값을 가지게 하고 싶은데 영한님께서도 이러한 고민을 하신적이 있으신지 궁금하고 어떻게 해결하셨을지도 궁금합니다~ 감사합니다.  

WhatsApp 채팅 아키텍처 설계에 대한 질문입니다. 영상에서는 참가자가 ws 서버에 메시지를 보내면 바로 Redis pub/sub으로 들어가고, 람다나 Stream을 통해 DB로 저장하는 방식을 설명하고 있습니다.하지만 DB 저장에 앞서 채팅방 참가 여부 검증, 메시지 전송 차단/해제, 구독자만 전송 가능 등의 검증(validation)이 필요한 경우가 있을 것 같습니다. 또한 이 경우 사용자에게 메시지 전송 실패/불가라는 즉각적인 피드백도 제공해줘야 할 것입니다. ws 서버에서는 보통 검증 로직은 담당하지 않는 것으로 알고 있는데, 이 경우 어디에 검증 로직을 넣는 게 적당할까요?

안녕하세요. 웹/백엔드 JAVA 개발자입니다.현재 SP를 실제로 사용할까요? (DB Procedure로 이해)(레거시 시스템 운영 외 현대의 서비스에서)일반적으로 SP 방식의 경우 강의 내용에서 나온버전 관리의 문제, 벤더 락인, 부분적 로직 재사용 등의 한계가 있어보여, 저는 줄곧 ORM에 적합한 환경이 아니더라도 SP 보다는 Application 레벨에서 Query를 작성&관리&실행하는 형태로 줄곧 서비스를 운영해왔고, 강의에서 언급된 ORM의 단점도 Application 에서 쿼리를 관리하면 사라지는 단점으로 보여져서, 사실상 SP는 지양해야 할 레거시 방식으로 생각하고 있었습니다.아직 다른 도메인 영역에서는 SP를 고수하는 분야가 있는걸까요?

안녕하세요. 강사님캐시전략 - Write-behind 전략을 설명해주셨는데,인스타라이브나 유튜브라이브에서 좋아요를 한 사용자가 여러번 누를 수 있는데, 이때가 아마 Write-behind 전략을 적용할 수 있을 거 같습니다.1. 좋아요를 레디스 캐시에 카운트 증가2. 좋아요 누른 개수를 몇 초마다 flush로 카프카 큐에 발행3. 카프카 consumer에서 db저장 이런 방식으로 설계가 가능할 거 같습니다. 강의에서는 Write-behind DB에 나중에 저장한다고 말씀하셨는데 그럼 이런 라이브 상황에서 DB에 좋아요를 언제 저장하는 것이 바람직할까요? 그 기준을 어떤 식으로 잡으면 좋을지도 선생님의 고견이 듣고 싶습니다.좋은 강의 감사합니다.  

 안녕하세요.JPA 강의를 듣다가 궁금한 점이 생겨 질문드립니다.JPA 강의에서는 일대일 관계를 설명하면서 Member가 FK를 가지고 있는 방식이 더 좋다고 설명하셨고 김영한님께서도 주 테이블에 FK를 두는 방식을 더 선호한다고 말씀하신 것으로 해했습니다.그래서 저는 일반적으로 주 테이블이 FK를 가지고 있는 방식이 더 편리하다고 생각하고 있었습니다.JPA 강의에서 해당 이미지로 설명하셨어요.  그런데 이번 강의에서는 보조 테이블이 FK를 가지고 있는 방식이 더 좋다고 설명되어서 조금 헷갈립니다.저는 화면의 예시에서 Member가 주테이블,Locker를 보조 테이블이라고 이해했는데 강의마다 설명이 반대되는 것처럼 느껴졌습니다.혹시 제가 잘못 이해한 부분이 있을까요?

다음 강의는 언제쯤 나오나요? 성능 최적화 배우고 싶습니다 😄

강의들을 때는 어렴풋이 알거 같고 근데 강의듣는거 끝내고 실제로 구별해보라고 하면 잘 못하는거 같아서요. 혹시 차이점을 예를들어서 좀 쉽게 설명해주실수 있을까요?저는 제 3 형 정규형 한거 같은데 또 보면 bcnf인거 같기도 하고 엄청 헷갈리고 있습니다. 도와주세요!제가 찾은 건 bcnf 가 후보키가 아니라 슈퍼키라고 나와서 더 헷갈리는 거 같아요.감사합니다. => 오랫동안 들여다 보고 이렇게 이해를 했는데 맞는지 모르겠습니다.기본적으로 슈퍼키가 아닌 일반키가 함수결정자가 되면 bcnf 위반이 되는거고 제 3 정규형은 슈퍼키가 함수결정자이거나 일반키가 함수결정자라도 결론쪽이 후보키 중에 일부이면 (prime attribute)이면 위반이안되는거 같습니다.

혹시 문제들 업데이트 안되나요 ??