안녕하세요 유익하고 훌륭한 강의 덕분에 쿼리 이해가 일취월장하고 있습니다. 감사합니다. 강사님께서 거듭 강조하시고 중요하다고 지적하신 "집합의 레벨"이 무슨 의미인지 문의드립니다. group by로 집계하거나 analytic sql로 데이터를 aggregate할 때 "집합의 레벨"이란 표현이 자주 나오는데 어떻게 이해하면 좋을까요? 하나의 행(레코드)가 여러 열(속성)을 가지는 경우에 있어서, 어느 하나의 열을 기준으로 다른 열의 값을 집계할 때, 그 기준이 되는 열을 집계결과의 '집합의 레벨' 이라고 이해하면 될까요? 이전 질문과 같이, 저도 첫 임시테이블(temp_01)에서 group by를 product_id와 category_id 두 열을 기준으로 했습니다. 여기서 첫 임시테이블의 '집합의 레벨'인 product_id이므로 category_id를 또다른 레벨로 두는 것이, 기능상 차이는 없지만 개념상 부적절하다고 생각하면 옳게 이해한 것일까요? "집합의 레벨"이라는 표현이 모호하게도 들으면 이해되는듯 하면서도 막상 쿼리를 작성할 때 머릿속에 원하는 결과가 흐릿해서 바라는 대로 결과를 얻지 못해 질문드립니다.
안녕하세요? 강사님 질문이 있습니다 Outer조인실습02 강의의 8분50초쯤에 city가 Madrid인 고객에 대해서 left join이 실행된다고 강조해주셨습니다 여기서 질문이 저는 sql 실행 순서가 from->where->groupby->... 로 알고 있는데 이 순서가 맞다면 from절에서 전체 고객에 대해 join을 다 수행 한 다음에 그 결과 테이블을 where 절로 city가 Mardrid 인 고객만 필터되는 것이 맞다고 생각드는데 이건 내부적으로 SQL이 최적화하면서 실행 순서를 무시(?)하는 것으로 받아들이면 되는걸까요? 감사합니다
안녕하세요? 강사님 머신러닝 강의에 이어서 SQL 강의도 잘 보고 있습니다 질문이 있는데 가령 3개의 테이블을 join할 경우 테이블a join 테이블b join 테이블c 이렇게 순서대로 join하는 것과 테이블a와 테이블b를 join하고 그 결과를 서브쿼리로 해서 테이블 d로 만들고 테이블c와 join하는 것과 성능적인 측면에서는 차이가 없는건지 궁금합니다
안녕하세요! 강의 정말 잘 듣고 있습니다!!!! 본 영상에서 첫번째 예시로 기간 범위에 따른 조회(1997년 주문)를 예시로 들어주셨는데 -- 강사님 예시 SELECT a.contact_name, a.address, b.order_id, b.order_date, b.shipped_date, b.ship_address FROM customers a JOIN orders b ON a.customer_id = b.customer_id WHERE a.contact_name = 'Antonio Moreno' AND b.order_date BETWEEN to_date('19970101', 'yyyymmdd') AND to_date('19971231', 'yyyymmdd'); 그런데 기간 범위를 설정할 때 1년 범위 설정 쿼리가 너무 길어보여서 다른 function들을 찾아서 적용해보았습니다. -- 수정1 SELECT a.contact_name, a.address, b.order_id, b.order_date, b.shipped_date, b.ship_address FROM customers a JOIN orders b ON a.customer_id = b.customer_id WHERE a.contact_name = 'Antonio Moreno' AND date_part('year', b.order_date) = '1997'; (물론 이쪽은 연도나 월 등 딱 하나만 인덱싱이 가능하니 한계는 있어보이네요.) 혹은 -- 수정2 SELECT a.contact_name, a.address, b.order_id, b.order_date, b.shipped_date, b.ship_address FROM customers a JOIN orders b ON a.customer_id = b.customer_id WHERE a.contact_name = 'Antonio Moreno' AND b.order_date BETWEEN '1997-01-01' AND '1997-12-31'; 이렇게 작성해도 결과물은 같긴 하더라고요. 강사님이 들어주신 예시의 to_date()는 검색해보니 대부분 오라클에서 많이 언급되는 것 같은데, 이쪽 쿼리가 더 범용적으로 사용되기에 사용하신 것인지, 아니면 다른 function도 딱히 문제는 없는 것인지 궁금합니다. 강의 최고입니다!! 감사합니다.
안녕하세요. 강사님의 강의를 잘 듣고 있는 와중, 일별 잔존율 SQL문에서 궁금증이 생겼습니다. SQL 로직을 보면 사용자 테이블과 세션 테이블을 left join 한 다음, 사용자 아이디, 생성일자, 방문일자로 그룹화하고, 다시 생성일자로 그룹화 한 후 생성일 기준 고유 사용자 수와 D+N 별 고유 사용자 수를 구하는 것으로 이해했습니다. 다만 세 컬럼으로 그룹화를 하게 되면, 아이디 생성일자 방문일자 U0179281 2016-10-24 2016-10-25 U0179281 2016-10-24 2016-10-26 와 같은 케이스가 나오게 되는데, 이를 다시 생성일자로 그룹화한 다음 count(*) 로 생성일 기준 모수를 구하게 되면 사용자 아이디는 중복으로 집계되는 것이 아닌지 궁금합니다. 생성일 기준 고유 사용자 수(모수)를 구하려면 10월 24일에 생성한 사용자 U0179281 1개만 집계되어야 하는게 아닌가 싶어 질문드립니다.
안녕하세요. 강의 잘 듣고 있습니다. 다음과 같이 여러 테이블을 join 후 하나의 row를 뽑아내려고 하는데 성능은 어떻게 나오는지 궁금합니다. select * from table1 inner join table2 on table1.xxx = table2.XXX inner join table3 on table2.XXX = table3.xxx where table1.nnn = NNN 이렇게 되어있을 때 전체가 다 join이 된 후 where 조건을 테스트 하게 된다면 데이터가 많을 경우 성능이 떨어질 것 같아서요. where 조건으로 먼저 필터링 한다면 금방 끝날 거 같긴한데 DB의 동작은 어떻게 처리되는건가요? 1. where 로 필터링이 되면서 join 되는것인지 아니면 join 완료 후 where로 필터링되는것인지 궁금합니다. 2. join의 횟수를 네다섯번씩 걸어도 성능에 무리가 없을까요? 3. 위 경우 한개의 컬럼만 찾으려면 limit을 추가해 주는게 나을까요? 1개 찾았을 때 전부 다 loop를 돌지 않고 빠져나가면 빠를거 같긴한데요. 확인 부탁드립니다.
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 자바로 예를 들자면 옛날에는 최적화를 위해 float, int같은 작은 단위들을 최대한 고려했었는데 컴퓨터 성능의 향상과 네트워크 속도 향상 저장 공간의 비용 절감 등의 이유로 지금은 거의 조금이라도 애매하면 모두 long, double을 선언해버리고 쓰는 것으로 알고 있습니다 마찬가지로 데이터베이스에서도 현실적으로 몇 바이트를 아끼기 위해 TINYINT같은 타입들을 사용하는 것이 크게 중요하지는 않은 일인가요? 아니면 수백수천만의 저장 데이터들이 들어오기 때문에 이런 부분까지도 신경써줘야 하는 것인가요? 실무에 계신 분의 의견이 궁금합니다 그리고 별개의 이야기지만 제가 인프런에서 들은 강의 중 가장 만족스럽고 너무 귀에 쏙쏙 박히는 강의입니다. 좋은 강의 만들어주셔서 감사합니다!
안녕하세요. 루키스님! 질문이 있는데요. "데이터베이스 원리" 챕터 강의는 CAP 이론을 물류 창고로 비유하여 설명하신 것 같습니다. 만약 그렇다면 3가지 항목이 다음과 같이 연결되는 것이 맞는지 궁금합니다. 1) 많이 - 네트워크 파티션 허용(Partition tolerance) - 2개의 물류 창고로 운영하면 많은 물건을 처리할 수 있지만 하나의 물류창고가 피해를 입어도 다른 하나를 사용할 수 있다고 생각합니다. 2) 빠르게 - 가용성(Availability) - 창고에서 언제나 물건을 꺼낼 수 있는 상황이라면 빠르 처리가 가능할 것으로 생각합니다. 3) 안전하게 - 일관성(Consistency) - 창고에서 꺼낸 물건이 정확하다는 것이 안전한 것이라고 생각합니다.
안녕하세요 오늘도 좋은 강의 감사합니다. 다름이 아니라 첫번째 with temp_01 as 쿼리를 시작하시는 부분에 질문이 있어요. 처음에 group by를 하실 때, product_id만 하시고 categroy_id는 크게 할 필요가 없으시다는 말씀을 하셨던 부분 이해를 완료했습니다. 그런데 선생님의 강의를 듣기 전에, 제가 문제를 먼저 풀었을 때 저는 group by에 category_id도 같이 추가를 하여 문제를 풀었습니다. 확인해보니 답은 동일하게 나왔더라고요. 그럼 제가 했던 방식으로 하여도 전혀 문제가 없는 것일까요? 혹시 몰라 제가 짰던 쿼리를 밑에 남겨놓겠습니다! (일부 알리아스 이름은 선생님께서 하신 부분과 비슷하게 맞춰놓았습니다) with temp_01 as ( select p.category_id , p.product_id , sum (oi.amount) sum_by_product -- 상품별 총합 from nw.order_items oi join nw.products p on oi.product_id = p.product_id group by p.category_id , p.product_id ), temp_02 as ( select category_id , product_id , sum_by_product , sum (sum_by_product) over ( partition by category_id) sum_by_category -- category별 총합 , row_number () over ( partition by category_id order by sum_by_product desc ) ranking_category -- 카테고리별 상품 순위 from temp_01 ) select * from temp_02 where sum_by_product >= 0.05*sum_by_category and ranking_category <= 3 order by category_id;
안녕하세요. 강사님. 수업 잘 듣고 있습니다. 제가 고민하던 부분과 연결시키면서 수업 듣고 있었는데 아직 고민이 되어 의견을 여쭤보고 싶어 질문 드립니다. 상품 테이블은 이미 있고 그 상품을 검색하는 해시태그(#) 검색 기능을 추가하기 위한 테이블 추가가 필요합니다. 기능은 1) 해시태그로 해당 해시태그가 등록된 상품을 검색 가능해야 합니다. 2) 상품별 해시태그도 알 수 있어야 합니다. 테이블 구성이 1:M 과 M:N 중에 고민이 됩니다. 상품과 태그는 1:M 수업에서 예로 들어주셨던 책-목차 처럼 '상품별 태그' 로 표현 가능하고 선천적으로 부모 자식 관계 같기도 하면서, 비지니스 관계처럼 '태그로 상품을 검색한다.' 가 표현이 됩니다. 하나의 상품이 여러 해시태그를 가질 수 있고, 하나의 해시태그도 여러 상품에 해당될 수 있으니 M:N 이 더 맞다고 생각이 들고 이렇게 진행하려는데 1:M 도 가능하지 않나 라는 의문이 남아서요. 1 테이블이 상품 테이블이면 M 테이블에서 컬럼을 상품ID(FK,PK), 해시태그(PK) 두개로 하면 기능적으로 다 가능합니다. 이런 경우는 1:M, M:N 중에 어떤 것이 더 나은 방향인지를 선택하는 기준이 있을까요?
훌륭한 강의를 듣고 있는 와중에 궁금점이 생겼습니다. group by 를 수행한 후에 주문 건수를 집계할 때 count(*) 함수 혹은 count(distinct order_id)를 사용하시던데, 주문 번호가 중복되어있을 경우에는 distinct 함수를 통해 중복을 제거후 count() 집계를 사용해야 된다고 알고 있습니다. 그런데 order별 특정 상품 주문시 함께 가장 많이 주문된 다른 상품 추출하기 쿼리에서, select prod_01, prod_02, count(*) from temp_01 group by prod_01, prod_02 부분을 보면 count(*)를 사용한 것이 이해가 잘 가지 않습니다 ㅠㅠ 그 앞의 temp_01 절에서 ga.order_items 테이블을 사용하는 데 해당 테이블에는 order_id가 중복되어 있는 것으로 알고 있습니다. 그러면 후에 건수 집계시 count(distinct temp_01.order_id)로 해야 하는 것이 아닌가 궁금합니다. 아니면 count(*)의 의미가 애초에 주문 건수를 의미하는 것이 아닌지 궁금합니다. 늘 수고 많으십니다.
현업에서 일을 하면서 가끔 부딪히는 문제인데 쿼리 요청 횟수를 줄이기 위해서 해당 레코드에 필요없는 데이터를 부득이하게 가져와야 하는 경우가 있는데 불필요한 열 참조를 하지 않기 위해서 쿼리 횟수를 늘리는 것이 좋은지 불필요한 열까지 가져오되 쿼리 횟수를 한번으로 하는 것이 좋은지 여쭙고 싶습니다.
