안녕하세요 영한님 마스터패스 구매하고 모든 강의를 재밌게 수강하고 있는 백엔드 개발자 취업준비생입니다. 강의를 듣다가 궁금한 점이 생겨 질문남깁니다! 답변해주시면 너무 감사하겠습니다. is_deleted 와 같은 컬럼을 사용하는 soft delete 방식은 실제 삭제 시점을 알 수 없기 때문에 주로 사용하진 않고, deleted_at을 컬럼으로 두고 삭제 여부/시점을 모두 판별할 수 있게 한다고 하셨는데, 그렇다면 뒤에 설명해주신 상태 기반 관리를 통해서 ProductStatus나 OrderStatus를 관리할 경우, deleted_at이나 다른 시점을 컬럼으로 두면 나쁜 설계라고 하셨습니다. 그렇다면 결국 ProductStatus와 같은 상태를 가진 것들은 삭제 시점이나 특정 시점을 알 수 없는건 마찬가지 아닌가요? 만약 삭제 시점이나 회원의 탈퇴 시점같은 것들을 관리해야 한다면 어떻게 해야할까요? 이러한 해결 방법으로써 이력 테이블 등의 방법이 있을 것 같은데 취준생의 개인 프로젝트로 사용하기에 규모가 너무 커지지 않을까 걱정됩니다. 실제 사례를 예시로 들어보자면 UserStatus 상태값입니다. 이를 테이블의 한 컬럼으로 두고 내부에는 ACTIVE(정상), SUSPENDED(임시정지), BANNED(영구정지), WITHDRAWN(탈퇴) 등의 여러 상태를 가집니다. 이때 만약 withdrawn_at 컬럼이 존재하지 않고 상태값만으로 관리하면 탈퇴 시점이 언제인지 등을 확인할 수 없게 됩니다. 이 경우에는 withdrawn_at 컬럼을 상태값과 함께 두는 것보다 이력 테이블을 사용하는게 더 나은 설계이자, 개인 소규모 프로젝트에서도 해당되는 사항인지 궁금합니다. 작은 조언이라도 해주시면 감사하겠습니다! -- 에이전트 인프런 에이전트에 같은 내용으로 질문을 남겨봤는데 withdrawn_at 컬럼을 상태 컬럼과 함께 사용하는 것이 효율적이고 합리적인 설계라고 합니다. 실제로 이력 테이블은 개인 프로젝트 규모정도에서는 사용하기에 관리 복잡도가 증가할 가능성이 있다고 합니다. 이에 대해 어떻게 생각하시는지도 궁금합니다.
안녕하세요 영한님! 강의 재밌게 잘 듣고있습니다. 아직 섹션3까지 들었는데 MySQL 아키텍처 설명을 너무 잘해주셔서 너무 재밌게 들었습니다! 개인적으로 실무에서 PostgreSQL을 사용하고 있는데 혹시 PostgreSQL 아키텍처 강의도 업데이트 예정이 있으신지 궁금합니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 오류인 부분이라 신고합니다. 76강 2분 33초 부분에서 transaction 설명을 위해 계좌에서 이체되는 부분 말씀 하실 때 A고객이 1만원 이체하여 잔금이 줄어 4만원인 부분을 작성하시고 연이어 B고객 부분을 말씀하실 때 이체를 받았으니 1만원이 되어야 한다고 하며 10000원으로 적으셨습니다. 하지만 내용 상 30000원이 되어야 하는 부분으로 보입니다.
member 테이블에서 회원의 가입일은 비즈니스 시간이라고 생각했는데, 이 컬럼은 왜 created_at 으로 시스템의 시간만을 의미하도록 되어 있는지 궁금합니다. ordered_at, paid_at 과 같이 가입일 컬럼이 따로 존재해야 하는게 아닌지 궁금합니다! 강의자료에 예시로 적어주신 것처럼 비즈니스 시간이 데이터베이스 수준에서 마이그레이션을 해야한다면 회원가입일을 보존할 수 없지 않을까요?
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] CASE문 단원 중 위의 '전체 GROUP BY'에서 '전체'라는 말이 오타인것 같아요~ CASE문 단원의 연습문제 4번 제시문 중 사용자 이름, 총 주문 건수, ` '전자기기' 주문 건수, '도서' 주문 건수를 각각 ~ 에서 '패션' 주문 건수라는 말이 누락되어 있는 것 같습니다. 영한님 강의 너무 잘듣고 있습니다!! 완강까지 힘내보겠습니다. 양질의 강의 진심으로 감사드립니다.
강의에서 배운 모델링을 바탕으로 프로젝트를 진행하려고 하는데 궁금한점이 생겼습니다. 1:1 관계인 orders 테이블과 delivery, pay 테이블의 관계에서 외래 키를 보조 테이블에 두었는데, jpa를 이용한 애플리케이션 코드에서는 일대일 관계에서 대상테이블에 외래 키를 두었을때 즉시로딩으로 N+1 문제가 발생할 수 있어서 orders엔티티에 외래 키를 두었습니다. 이때 db와 애플리케이션 간에 테이블 구조가 불일치하기 때문에 오류가 발생할 것으로 예상됩니다. 이 경우 주문과 배송, 결제 정보가 같이 생성된다고 보고 외래 키 위치를 주 테이블에 두어야할까요? 아니면 애플리케이션 코드에서 즉시로딩 문제를 해결해야할까요?
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (강의 실습이후 발생되는 상황 ) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 세션 10. 데이터 무결성 - check 제약조건을 설명하기 위해서, orders 테이블이랑 products 테이블을 지우셨습니다. 사진 처럼 요 그 이후에 워크벤치를 껏다 킨 이후에 my_shop2 db를 보니 my_shop 랑 다르게, @@@ could not be fetched 라는 내용이 발생한다는 것을 알수 있었는데요. orders에 있던 여러 내용 들이 없어져서 이런 문제가 났겠다는 것을 알 수 있었습니다. 이런 경우 view에 남아있는 ordes랑 연결되어있는 조건들때문에 문제가 생겼으니 view에 대한것들을 없애면 원래대로 되는지 알고싶습니다.
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. 궁금증이 생겨서 질문을 드립니다. 'case문 - 문제와 풀이 - 1번 문제'에서 영한님은 사진 위쪽 부분 case 문 옆에 category 를 써서 단순 case문으로 해결 하였는데요. 여기서 저는 사진 아래쪽 부분에 적힌대로 category = '전자기기' 를 써서 해결하였습니다. 여기서 질문 입니다. category = '전자기기' 이 코드 처럼 해도, 상관 없는지 알고 싶습니다. + 아래 처럼 한 이유는 위에 쿼리문은 완전히 생각이 안났습니다.
안녕하세요 ^^ 아주 작지만 소소한 정오표 전달드립니다. 7. 논리적 모델링3 - 일대일, 다대다 관계 49페이지 AS-IS 우리가 실제 '수강신청 시스템'을로 만든다고 TO-BE 우리가 실제로 '수강신청 시스템'을 만든다고 마우스 드래그 하는 중에 바뀌는 부분 확인했습니다! 항상 감사합니다!
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 안녕하세요. mysql 워크벤치를 실행 할때 오류가 떠서 질문을 남깁니다. 사진처럼 이렇게 나옵니다. 그래서 맨 처음 에는 '리스토어 워크벤치 오류' 을 치고 따라 해보았지만, 컴퓨터를 다시 키고 워크벤치를 실행하면 이사진 속 에러가 계속 나옵니다. 어떻게 해야 해결이 가능할까요? + 취소 하고 하면 sql 은실행 가능 합니다. 답변 부탁 드립니다.
안녕하세요 선생님, 실제 필드에선 클라이언트의 요구 사항이 명확하지 않고, 기획자가 없으며, 개발자가 대부분의 일을 다 해내야 하는 경우가 있는데, 클라이언트(대표님 또는 상사)와 소통, 기획서 작성, 설계, 개발까지 혼자 하게 될 때 현명하게 대처하는 방법은 뭐가 있을까요? 큰 기업은 각자의 업무에 집중할 수 있겠지만, 작은 기업은 그게 쉽지 않은 걸 알고 있습니다 클라이언트와 소통, 화면 기획 및 요구 사항 작성등은 어떤식으로 공부해야할까요?
안녕하세요. 공통 코드와 계층 구조 관련해서 질문이 있어 질문 드립니다. 이전에 경험했던 프로젝트 보면 공통 코드와 계층 구조 테이블을 다 합친 일명 '만능 코드 테이블' 에 모두 넣고 사용하는 방식도 사용했는데 이번 공통 코드(자연키, 복합키) 강의와, 계층 구조의 강의를 들으며 시야가 또 달라지네요. 예를 들면 주문 상태 코드와, 상품 코드를 하나의 테이블의 대체키, 외래키를 적용해서 사용했었네요. 혹시 '만능 코드 테이블'의 경우는 추후 유지보수와 개발 편의 관점에서 개선해야하는 부분이 맞겠지요? 만약에 개선하게 된다면, 어떤 기준으로 나누면 될지. 설계적 관점에 대해 혜안을 듣고 싶습니다. 예를 들면, 공통 코드 테이블 2개와, 계층 테이블 이렇게 두고 계층의 가능성으로 보통 나누는지 궁금하고, 추가로 도메인 성격까지 고려해서 테이블을 또 쪼개는지 등이 궁금합니다. 그리고 CS 팀에서 고객 문의 사항에 문의 유형을 최초 상품, 주문, 배송 이런식으로 공통 코드에 넣어서 사용하고 있었는데, 갑자기 정책이 바뀌면서 주문 하위에 주문 오류, 주문 취소 등 하위 개념이 생기면 계층 테이블로 옮겨야 할 거 같은데 이런 경우는 애초에 기획당시에 개발자가 확장 가능성에 대해 고민을 하고 공통 테이블로 넣었으면 안되는 것인지에 대한 부분도 궁금하네요. 매번 질높은 강의로 도움주셔서 감사합니다!
