173만명의 커뮤니티!! 함께 토론해봐요.
미해결
[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
안녕하세요. 강의를 위해 질문 남깁니다. 2024년 개정된책이어서 그런지 책에 문제 내용이랑 다르네요. 책에는 tbl c1 c2 A 100 B 200 B 100 B NULL NULL 200 라서 답은 200입니다.
미해결
[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
안녕하세요. 시험이 바로 내일이지만 이상한 것 같아 질문드립니다. CONNECT BY PRIOR 부모 = 자식 순방향 CONNECT BY 자식 = PRIOR 부모 도 순방향, CONNECT BY 부모 = PRIOR 자식 역방향 CONNECT BY PRIOR 자식 = 부모 도 역방향 으로 알고있습니다. PRIOR 위치에 따라 달라지는게 아니라 테이블의 기준으로 순방향 역방향이 정해지는걸로 알고있습니다. 그리고 부모가 부서코드, 자식이 상위부서코드 아닌가요? 확인 부탁드리겠습니다.
미해결
[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
안녕하세요. 시험이 얼마남지 않아. 옳바른 공부법은 아니지만 문제푸는 관점만 맞는지 여쭤보고싶습니다. 2,3차 정규화가 좀 헷갈리는데 둘 다 a가 b를 결정(a만 알면 b는 따라나옴,ex.학번을 알면 이름 학과는 알 수 있음)에서 a가 pk이면 2차, a가 일반속성이면 3차 정규화라고 생각해도 될까요?
미해결
[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
실전 모의고사 난이도가 실제 시험과 유사한 수준인가요?
해결됨
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
안녕하세요, Part2 기출 문제 및 해설 자료 다운로드 시, 파일이 없어서 글 남깁니다. 아래 자료도 다운로드 시, 동일한 상황입니다. Part2 기출 풀이(3) - 21-30번 문제 Part2 기출 풀이(3) - 31-40번 문제
미해결
[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
마지막 설명에서 별칭이 선언되었을때 숫자로 호출하면 안된다는 이야기를 하시는건가요?
미해결
[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
답은 2번으로 되어 있는데 첨부해주신 해설 내용은 3번이어서요~~개수가 두개인 3번이 답 아닌가요?
해결됨
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요, 유저 테이블과 구독 테이블 설계 중 해결하기 까다로운 지점이 생겨 질문드립니다. *현재 상황을 보다 이해하시는데 문제가 없으시기 위해 ai로 질문을 정리한점 먼저 말씀드립니다. 1. 현재 상황 및 서비스 정책 유저 테이블: id(PK) , email(UK) / 탈퇴 시 소프트 삭제, 개인정보 보호를 위해 이메일 마스킹 필수. 구독 테이블: 현재 활성화된 구독 정보 딱 1건만 관리 (이력은 별도 테이블 존재). 서비스 정책: 탈퇴 후 동일 이메일로 재가입 시, 기존 로우 복구가 아니라 새로운 로우로 Insert 됩니다. 단, 재가입 시 과거 구독 정보는 그대로 이어받아야 합니다. 2. 제가 고민해 본 방법들과 예상되는 문제점 생각한 방법 1) 구독 테이블이 유저 PK( id )를 외래키로 바라보게 한다. 예상 문제: 재가입 시 유저 테이블에 새 로우가 Insert 되면서 새로운 PK를 발급받기 때문에, 과거 PK를 바라보고 있던 구독 테이블과 연결 고리가 끊어집니다. 생각한 방법 2) 유저 테이블에 '이메일 해시(유니크X)'를 두고, 구독 테이블과 해시값으로 매핑한다. 예상 문제: 해시는 개인정보가 아니므로 탈퇴 후에도 유저 테이블에 남겨둘 수 있어 재가입 매칭은 가능합니다. 하지만 유저가 중간에 이메일을 변경하는 경우 , 유저 테이블의 이메일 해시뿐만 아니라 구독 테이블 및 구독 이력 테이블의 해시값까지 전부 동시 UPDATE 쳐야 하는 번거로움이 생깁니다. 3. 질문 요약 개인정보 보호를 위해 유저 테이블의 이메일 원본은 마스킹하면서도, 재가입 시 동일인임을 식별해 과거 구독 정보를 매칭해 주어야 합니다. 여기에 유저의 이메일 변경 가능성까지 고려해야 하는 상황입니다. 이 경우 구독 테이블의 매핑 키 체계를 어떻게 잡는 것이 가장 깔끔하고 현명한 DB 설계 원칙 일까요? 실무에서 이런 케이스를 해결하는 정석적인 아키텍처 가이드가 궁금합니다!
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
자연키vs대리키 강의를 보면 대리키를 사용하는게 안정성,유연성에 있어 많은 장점이 있어 대부분 대리키를 사용한다고 하셨는대, 다음과 같은 케이스에도 대리키를 쓰는게 좋을지 궁금합니다. (뒤에 강의에 나올수도 있지만 현시점 궁금해서 질문드립니다.) 1. 조인테이블의 경우 a,b테이블의 pk인 대리키를 이용해 복합키를 만들어서 pk로 쓰면 될지, 아니면 그것 역시 따로 대리키를 만들어야 할지 궁금합니다. 2. 정말 단순한 enum 형태의 테이블일 경우, 예를 들어 유저상태값을 표현하기위해 정상,휴면,탈퇴 등을 기록하는 테이블의 경우 자연키, 대리키 어떤거를 써야할지 궁금합니다. 제가 경험한 바로는 enum 형태의 간단한 테이블조차 대리키를 사용하니 유저 테이블을 조회할때 간단한 상태값조차 조인을 해서 봐야하니 불편하더라고요. 감사합니다.
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
보기 3번 4번 구문이 실행은 되지만 궁금해서 질문 드립니다. rollup (col1, (col1, col2))를 풀어서 쓰면 (co1, col1, col2), (col1), () 이렇게 나오는데 보통은 rollup(col1, col2)로 쓰지않나요? cube도 비슷한것 같습니다. 그룹핑은 중복이 제거 되서 실행 되는 것 같은데 보통은 안쓰는 것 같아서 질문드립니다.
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
14번문제 보기 1번이 약간 애매해서 질문드립니다. cube는 모든 조합을 하고 rollup이 순서에따라 달라지는거 아닐까요? ex cube(a, b) = (a, b), a, b, () 이고 rollup(a, b) = (a, b), a, () 인데 cube는 순서를 바꿔도 같은내용인데 rollup은 순서를 바꾸면 달라지는거 아닌가요?
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
언제 발급될까요? 서식 작성했습니다!:D
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요 우선 값진 강의 만들어주셔서 감사드립니다. 취준을 하며 개인 프로젝트를 진행 중인데, 고민 해오던 부분들에 많은 도움이 되었습니다. 강의를 완강하고, 학습한 내용들을 바탕으로 이전에 진행했던 프로젝트의 DB를 재검토하고 재설계 해보고 있습니다. 구글링, 해당 게시판에 올라온 이전 질문들 참고하고 ai와 대화를 하고도 완전하게 확신이 서지 않는 부분이 있어서 질문드립니다. 우선 제가 만들고 있는 서비스는 "좌석이 있는 공연 예매 시스템" 입니다. 공연 데이터 생성시 해당 공연의 좌석들이 함께 생성됩니다. 즉 특정 공연의 특정 좌석들이 고유하게 생성됩니다. 그리고 사용자는 좌석을 다중 선택하여 선점하고 예매할 수 있습니다. (예매 - 좌석) 관계는 (1:N) 입니다. 그래서 기존 DB 에서는 N 쪽인 좌석이 예매 id 를 fk 로 들고 있는 간단한 형태로 진행하였습니다. 그런데 강의 중 다대다(M:N) 관계 부분에서 연결 테이블의 본질이 관계 자체를 하나의 독립된 데이터로 보고 , 그것을 테이블로 모델링 하는 것 이라는 내용을 접하고, 비록 1:N 관계이지만, 예매 - 좌석 관계가 엔티티로 승격될만 한가에 대한 고민을 했습니다. (강의에서 예시로 사용된 주문 - 주문상품 - 상품 을 보며, 좌석을 수량이 단 하나뿐인 상품이라고 생각한다면 예매 - 예매좌석 - 좌석 형태가 비슷하다고 생각했습니다.) 이유가 충분하다면 실무에서도 N:M 관계에서 뿐만 아니라 1:N 관계에서도 중간테이블 (연관엔티티)를 두는 설계를 실제로 하는지, 현재 상황에서도 (질문이 너무 길어지고 복잡해질까봐 제가 판단한 이유들을 설명드리진 않았지만) 연관관계 엔티티를 두는 것이 타당한 판단일지 고견 여쭈어봅니다. 긴 질문 읽어주셔서 감사합니다!
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
보기 중에 '속성은 하나의 값만 가진다.' 라는 보기가 맞는 보기로 해설이 되어있는데, 바로 직전에 설명하신 다중 값 속성(전화번호, 이메일) 이라는게 있지 않나요?
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
먼저 유사한 질문이 있었는지 검색해보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 49번 문제 해설에는 david phone에 문자가 포함됐다고 하는데 문제에는 숫자만 있는 것 같습니다. 확인 부탁드리겠습니다.
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
안녕하세요, 공통코드 관련하여 코드그룹, 코드상세 테이블 설계 강의 잘 들었습니다. 관련하여 2가지 질문이 있습니다! 1. 혹시 사내에 dataware라는 메타시스템을 사용할 경우에는 어떤 식으로 운영을 하는지 궁금합니다. 전 회사에서는 메타시스템은 단순 정의 용도로 사용하고, 모든 코드값은 enum으로 사용을 했었는데요~ 강의 내용에 있는 것처럼 값이 바뀔 때마다 계속 재배포 작업을 해야 하긴 했지만, 그 외에 특별한 이슈는 없었던 것 같습니다. (배치성 프로젝트라 빠른 대응이 필요하지 않았음) 현 회사에서는 아직 정해진 정책은 없지만, 메타DB를 어플리케이션에서 접근할 수 있도록 하는 방법은 어떨지도 고민하고 있습니다. 그래서 일반적으로는 메타시스템, 공통코드 테이블, enum을 어떤 식으로 mix하여 사용하는지 궁금합니다. 추가로 고유한 컬럼 인식을 위해 최대한 유니크한 컬럼명을 사용하고 있는데요~ 예를 들어, 사용자로그인상태코드라는 컬럼이 있더라도 사이트에 따라 아래처럼 분리하는 경우가 존재합니다. A사이트사용자로그인상태코드 B사이트사용자로그인상태코드 이 경우 같은 아래처럼 코드값을 다르게 정의할 경우 현실적으로 체크하는 것이 좀 어려운 것 같습니다. A사이트의 경우 0:정상, 1:잠금, 2:정지, 3:휴면, 4:탈퇴 B사이트의 경우 0:정상, 1:잠금, 2:탈퇴, 3:휴면 (B사이트는 정지 상태가 없음) 같은 의미의 코드일 경우 같은 코드값을 가지게 하고 싶은데 영한님께서도 이러한 고민을 하신적이 있으신지 궁금하고 어떻게 해결하셨을지도 궁금합니다~ 감사합니다.
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
먼저 유사한 질문이 있었는지 검색해보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. TO_CHAR(HIREDATE, 'YYYY') 대신 EXTRACT (YEAR FROM HIREDATE) 이거를 쓰는 이유가 뭘까요?
미해결
김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
안녕하세요. JPA 강의를 듣다가 궁금한 점이 생겨 질문드립니다. JPA 강의에서는 일대일 관계를 설명하면서 Member가 FK를 가지고 있는 방식이 더 좋다고 설명하셨고 김영한님께서도 주 테이블에 FK를 두는 방식을 더 선호한다고 말씀하신 것으로 해했습니다. 그래서 저는 일반적으로 주 테이블이 FK를 가지고 있는 방식이 더 편리하다고 생각하고 있었습니다. JPA 강의에서 해당 이미지로 설명하셨어요. 그런데 이번 강의에서는 보조 테이블이 FK를 가지고 있는 방식이 더 좋다고 설명되어서 조금 헷갈립니다. 저는 화면의 예시에서 Member가 주테이블, Locker를 보조 테이블이라고 이해했는데 강의마다 설명이 반대되는 것처럼 느껴졌습니다. 혹시 제가 잘못 이해한 부분이 있을까요?
미해결
[2026] 비전공자도 한 번에 합격하는 SQLD 올인원
먼저 유사한 질문이 있었는지 검색해보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 실습 1번문제 쿼리는 맞게 했는데 왜 값이 다르게 나올까요 ?
미해결
김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
다음 강의는 언제쯤 나오나요? 성능 최적화 배우고 싶습니다 😄
