묻고 답해요
164만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결김영한의 실전 데이터베이스 - 기본편
9. 인덱스2.pdf 중에서
[4페이지 - 예시 2]하나는 "~", 다른 하나는 "AND"인 부분 뭔가 어색?한 거 같습니다.
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
역할 및 발생 시점에 따른 엔티티 분류
역할 및 발생 시점에 따른 엔티티 분류를 설명하는 파트에서 궁금한 점이 있습니다. 지난 강의까지 주문 엔티티는 사건 발생의 결과물(즉, 주문 이력)이 기록되는 엔티티라고 이해했었는데요."엔티티 분류1" 강의에서는 기본, 중심, 행위 엔티티로 나눠서 생각해볼 수 있다고 했습니다. 그때 중심 엔티티에서도 예시가 주문으로 나와있고, 행위 엔티티에서도 주문 이력으로 나와 있는데, 이 두 개가 다른 경우인가요? 중심 엔티티의 주문과 행위 엔티티의 차이가 무엇인가요? 감사합니다.
-
미해결김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
NOT NULL과 DEFAULT 조건의 사용법
강의에서 stock_quantity 칼럼의 제약 조건으로 다음과 같은 구문을 작성하였는데,stock_quantity INT NOT NULL DEFAULT 0해당 구문에서 NOT NULL 제약조건을 두지 않더라도 DEFAULT 0만 작성하여도 충분히 해당 칼럼이 NULL값이 되는 걸 방지할 수 있으리라 생각이 되어서요. NOT NULL 제약조건을 반드시 작성해야하는 걸까요? 아니면 개발자의 코드 작성 의도를 더 명확히 하고자 작성하는 걸까요?
-
해결됨김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
대리키의 외부 노출에 대한 질문을 하고 싶습니다.
안녕하세요. 사이드 프로젝트를 설계하다 보면 테이블의 키를 어떻게 가져갈지 고민을 많이 하게됩니다. 영한님의 말씀대로 대부분 대체키로 만들지만 숫자 대체키의 경우 1부터 순차적으로 올라가게 대부분 구조가 만들어지게 됩니다. 이게 혹여나 보안에 우려가 있을까 염려됩니다. 안전하게 UUID로 대체키를 주면 강의에서 말씀해 주신것 처럼 성능 부분에서 trade off가 있어서 이 방법도 고민됩니다. 예를 들어서 회원이라면 회원 정보를 조회하는 GET API에 회원ID(숫자 대리키, pk) 를 보내면 해당 유저 정보를 조회하게 되는데 숫자를 임의로 바꿔서 다른 유저 정보를 조회하는 이런 부분에서 혹여나 보안 관점에서 우려가 있지 않을까? 생각을 갖게 됩니다. 그러다 보니 두 가지 방안이 떠오르는데 실무에서 추천해주실 방안이 있는지 궁금합니다. 대체키(숫자)를 사용하되 애플리케이션에서 validation을 확실하게 설정pk는 대체키(숫자, pk)를 하되 db에서 join, 외래키로만 사용하고 외부로 나갈 때는 다른 대체키(UUID, unique)로만 보내는 방식영한님을 기다리며... 답변에 미리 감사드립니다.
-
미해결김영한의 실전 데이터베이스 - 기본편
문제 2번
문제 2번에서두 그룹의 목록을 중복 제거 없이 모두 합쳐서 조회해라. 라고 문제가 나오는데어째서 distinct를 이용하는건가요? 중복을 제거하고 합치는게 의도였다면 정답에 션과 네이트도 중복이 제거가 돼야 중복 제거가 의도라고 이해할텐데 distinct를 사용한 의도를 잘 모르겠어요
-
미해결[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
실전문제 2회차 24번문제
해당문제에서 답은 3번이라고 되어있긴한데요. 1번 보기도 의미상 맞긴한것 같아서 문의드립니디다.1번 보기도 의미상 연속된 3일에 한하여 추출하는거 같은데요. 만일 날짜가 하루이틀 건너서 생긴다면 그건 제외되겠지만 문제가 연속된 3일이잖아요..정답으로 체크되어있는 3번 보기도 딱 연속적인 3일에 대해서만 같은 GRP로 그룹핑되는것 같은데요... 그런데
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
소프트 딜리트 정책에서 유니크 컬럼 중복 방지 전략
유니크 제약조건에 대해 질문드립니다. 예를 들어 핸드폰 번호당 계정을 하나만 가질 수 있어서 핸드폰 컬럼을 유니크제약을 걸었습니다.특정 회원이 탈퇴할 때 하드 딜리트가 아니라 소프트 딜리트를 하는 정책일 경우, 탈퇴 했던 유저가 다시 가입하게되면 어떻게 해줘야할까요.? 그럼 결국 유니크 제약을 디비에서 없애고, 애플리케이션 단에서 제어를 해야할까요?
-
해결됨김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
대리키 사용과 정규화
정규화와 정규형을 생각할 때는 자연키를 사용한다는 것을 가정해야할까요?예를 들어,회원 테이블을 회원id (대리키), 아이디(자연키), 비밀번호, 이메일 속성으로 정의할 때, 회원id 는 아이디를 결정하고 (회원id -> 아이디), 아이디는 비밀번호, 이메일을 결정하므로 (아이디 -> 비밀번호, 아이디 -> 이메일) 이행함수 종속이 발생하는 것처럼 보입니다. 이처럼 정규화와 정규형을 생각할 때에는 대리키 개념을 배제하고, 자연키를 기준으로 생각해야할까요?
-
미해결김영한의 실전 데이터베이스 - 기본편
문제와 풀이1 - 3번 문제
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]안녕하세요 영한님, 강의 정말 재밌게 봤습니다!다름이 아니라 문제와 풀이 3번 문제 "RIGHT JOIN으로 주문 없는 고객 찾기"를 보면 '가입은 했지만 주문 기록이 없는 고객의 이름과 이메일을 조회하는 SQL을 작성하라고 되어있는데, DISTINCT를 붙여 중복을 제거한 행을 조회하는게 맞는게 아닌가 싶어 질문 드립니다!! -- 기존 답안 SELECT u.name, u.email FROM orders o RIGHT JOIN users u on o.user_id = u.user_id WHERE o.order_id IS NULL; -- 제가 생각한 쿼리문 SELECT DISTINCT u.name, u.email FROM orders o RIGHT JOIN users u on o.user_id = u.user_id WHERE o.order_id IS NULL;
-
미해결실습으로 손에 잡히는 SQLD(2과목)
윈도우 환경설정 오류 도움 요청드립니다~
위와 같이 오류가 발생한 상황인데 어떻게 해결할 수 있을까요?
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
강의자료 까마귀발 잘못된거 아닌가요?
결제와 주문, 배송과 주문 관계까 1대1인데 결제, 배송 쪽 관계 표시가 선택적1로 되어 있는데 잘못된거 아닌가요'?
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
신입이나 취준생의 사이트 프로젝트 개발 순서 어떻게 되나요?
사이드프로젝트로 백엔드 시스템을 개발할때 어떤 순서로 해야되나요? 데이터베이스 설계를 먼저 한 뒤에 코드작성을 시작해야되나요? 그리고 만약 개발과정에서 처음 설계한 데이터베이스 규칙에 위반되는 코드가 나온다면 어떻게 해야하나요?
-
해결됨[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
실전문제3회 41번문제
분기별 매출 실적과 전년 동기 대비 증감률 문제요1번이나 3번이나 동일한 결과값 아닌가요?:실제 두개값 minus하니까 일치하는걸로 나오던데요.. 1번보기:SELECT YEAR, QUARTER, AMOUNT,LAG(AMOUNT) OVER (PARTITION BY QUARTER ORDER BY YEAR) as PREV_AMOUNT,ROUND((AMOUNT - LAG(AMOUNT) OVER (PARTITION BY QUARTER ORDER BY YEAR)) /LAG(AMOUNT) OVER (PARTITION BY QUARTER ORDER BY YEAR) * 100, 2) as GROWTH_RATEfrom SALES; 3번보기:SELECT YEAR, QUARTER, AMOUNT,LAG(AMOUNT, 4) OVER (ORDER BY YEAR, QUARTER) as PREV_AMOUNT,ROUND((AMOUNT - LAG(AMOUNT, 4) OVER (ORDER BY YEAR, QUARTER)) /LAG(AMOUNT, 4) OVER (ORDER BY YEAR, QUARTER) * 100, 2) as GROWTH_RATEFROM SALES;
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
AI 질문 관련하여 문의드립니다.
안녕하세요 영한님. 강의를 들으면서 파편화된 정보를 정리하고 있어 너무 즐겁게 강의를 듣고 있습니다. 그런데 AI 퀴즈를 풀던 중 해당 퀴즈에서 뭔가 의아함을 느껴 질문드립니다. 물론 A를 토대로, 외래 키 컬럼에 NULL을 허용함으로써 선택적 참여를 구현할 수 있다는 것까지는 이해할 수 있겠습니다. 다만 [별도 참여 테이블 생성]이 위에 말씀 주신 member를 생성하는 것이라면 B가 더 적합한 선택지라는 생각이 듭니다. 혹시 [별도 참여 테이블 생성]이라는 선택지는 team / member 외의 테이블을 하나 더 만드는 것을 의미했던 걸까요? 비롯해서 해설에 있는 [맞을까요?]라는 질문이 적절하지 않게 느껴지는데요. 인프런으로 문의드릴까 하다가, 문제에 대한 질문을 드리는 것은 이쪽이 맞을 것 같아서 QnA로 질문드립니다!
-
미해결[2026] SQLD 문제가 어려운 당신을 위한 노랭이 176 문제 풀이
실전문제 3회차 18번
부서별 급여가 가장 높은 직원을 조회하는 SQL문 문제에서 보기중에 아래 2개가 동일한것 같은데 1번보기랑 3번보기랑 같은거 같은데 왜 답이 3번이예요? 1번 쿼리에 문제가있나요?1. SELECT * FROM EMPLOYEE WHERE (DEPT_ID, SALARY) IN (SELECT DEPT_ID, MAX(SALARY) FROM EMPLOYEE GROUP BY DEPT_ID); 3.SELECT * FROM EMPLOYEE E WHERE SALARY = (SELECT MAX(SALARY) FROM EMPLOYEE WHERE DEPT_ID = E.DEPT_ID)
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
프론트엔드 개발자와도 함께 협업 할때 용어 사전 같은걸 함께 작성 하나요 ?
프론트엔드 개발자와 함께 작업을 하게 된다면 용어 사전같은 프로젝드 관련 파일들을 공유 하는지 궁금 합니다.
-
해결됨김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
순환 외래키 제약조건(A→B→C→A)으로 인해 삭제가 불가능할 때 해결 방법이 궁금합니다
A, B, C 이렇게 세 개의 테이블이 있는데요,A → B, B → C, C → A 이렇게 서로 참조하고 있는 구조입니다.문제는 이렇게 되어 있으니까,예를 들어 B를 지우려면 A가 걸리고,A를 지우려면 또 C가 걸리고,C를 지우려면 다시 A가 걸려서결국 서로 물려서 삭제가 안 되는 상황이 생깁니다.예를 들면A = 학생(Student) → 어떤 수업(B) 에 참여하고,B = 수업(Class) → 그 수업은 교사(C) 가 담당하며,C = 교사(Teacher) → 교사는 자신이 가르치는 학생(A) 들의 리스트를 참조(관리용).이 예시는 정확한 상황은 아니고 제가 생각해서 만들어낸 예시입니다 조금 안맞을수 있는데 만약에 이런 경우에 보통 어떻게 처리해야하나요?
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
JPA에서 엔티티 정의시에 시간 타입 정의에 대해서.
어떻게 보면 이 수업과는 조금은 먼 이야기일수도 있는데 실제 프로젝트에서 JPA를 다루다보니 엔티티 선언시에 시간 타입 정의를 어떻게 처리해야 할지가 항상 고민이 되더라구요. 현재 프로젝트에서는 Entity 정의시에는 Instant를 사용을 하는데, 혹시 추천하시는 방법이 있을까요??
-
미해결김영한의 실전 데이터베이스 - 기본편
잘 사용하진 않지만 풀 외부 조인을 사용하신 사례가 궁금합니다!
풀 외부 조인을 잘 사용하지는 않지만 가끔 사용하실 때가 있다고 했는데 어떨 때 사용하셨는지 궁금합니다.
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
실무에서도 외래 키를 쓸수 있지만 쓰지 않는 경우?
실무에서도 외래 키(Foreign Key)를 쓸수 있는 상황이지만특별히 쓰지않고 처리하는 경우가 있을까요? 예를 들어 시스템 초기에 보다 유연한 설계를 위해?데이터 보전을 위해? 아니면 쓸수 있으면 최대한 쓰는게 맞을까요?