SELECT, FROM, ORDER BY, LIMIT 실습 파트 중입니다!mbtitest 테이블을 mbti_test로 다르게 설정하기는 했지만 다른 부분에 있어서는 동일하게 진행했습니다!그런데 컬럼 추출하려니까 에러가 떠서요그레이브를 잘 못 입력했나 싶기는 한데... 한 번 봐주시면 감사드리겠습니다!🙏T, F, ORDER BY, LIMIT 실습T,M, ORDER BY, LIMIT 실습

카일님, 안녕하세요! 시간 데이터 3번 문제 궁금한게 있어 질문드립니다.저는 해당 문제를 서브쿼리 없이 작성했는데, 서브쿼리 없이 작성해도 문제가 없나요?그리고 서브쿼리는 어떤 경우에 사용해야 하는지 기준이 있을까요??SELECT trainer_id, FORMAT_DATE("%d/%m/%Y", MIN(DATE(catch_datetime, 'Asia/Seoul'))) as first_date FROM basic.trainer_pokemon GROUP BY trainer_id ORDER BY trainer_id;

안녕하세요. 연습문제 2번을 다음과 같이 풀어보았습니다. Q: 리텐션 연습문제: Retain User를 New, Current, Resurrected, Dormant User로 나누는 쿼리를 작성하여라. 주어진 데이터에서 어떤 사람들이 리텐션이 그나마 높은지, 찾아보아라.주차별, 전체 유저에 대한 코호트 분석 그래프를 보면, 다음과 같습니다. 문제 정의2022년 12월 19일 이후로 리텐션이 떨어지고 있는 문제점이 발생했다. 해당 원인이 무엇일까?가설 설정1) 고객의 유입량이 감소하고 있다.-> 2022년 12월 19일 이전과 이후의 주차별 신규 가입자 수를 비교한다.2) 리텐션의 변화가 특정 유저 그룹에 의해 영향을 받는가?-> 신규유저는 어떤 시점을 기준으로 분류할 것인가?주차별 신규 가입자 수 시각화2022년 12월 19일을 월요일로 하는 주차부터 신규 가입자 수가 감소하는 추세이다. 전반적으로 신규가입자 수는 증가하는 추세였으나, 12월 19일을 기점으로 꺾이는 현상을 보인다. 따라서, 신규 가입자 수가 리텐션에 영향을 준다는 것을 확인할 수 있다.기존의 추세와 반하게, 떨어지는 추세를 보이기 때문에 다음과 같이 기존 유저와 신규 유저를 정의하겠다.1) 기존 유저=> 2022년 10월 03일 ~ 2022년 12월 19일 이전2) 신규 유저=> 2022년 12월 19일 이후복귀유저와 이탈 유저를 판단하는 기준이 필요하다. 이를 위해, 첫 로그인 이후, 두번째로 로그인을 하기까지의 걸리는 시간을 4분위 수로 검증해서, 중위값을 기준으로 기존유저와 복귀유저를 구분해보기로 했다.로그인 판단 기준 = click_login 이라는 이벤트가 발생했을 경우1. 자동 로그인 여부 판단SELECT COUNT(*) FROM advanced.app_logs CROSS JOIN UNNEST(event_params) AS ep WHERE ep.key = "firebase_screen" AND ep.value.string_value = 'welcome' AND user_id IS NOT NULL자동 로그인이 된다면, click_login 이벤트가 발생하지 않을 것이다. 하지만, COUNT(*)가 0이기 때문에, 해당 앱은 자동 로그인이 되지 않음을 알 수 있다.즉, 사용자가 앱에 접속하면, 가입을 했더라도, 무조건 로그인을 해야한다. 따라서, 사용자가 앱에 접속 시, 로그인 이벤트가 무조건 발생한다.2.첫번째 로그인 후, 다음 로그인하기까지 걸린 시간을 4분위 수로 계산WITH base AS (SELECT event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_timestamp, user_pseudo_id, event_name, ROW_NUMBER() OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS login_rn FROM advanced.app_logs WHERE event_name = 'click_login' AND event_date >= '2022-10-03' QUALIFY login_rn < 3) , second_event_data AS (SELECT event_date, event_timestamp, user_pseudo_id, event_name, login_rn, IF(second_event_date IS NULL, '2023-01-20', second_event_date) AS second_event_date FROM (SELECT *, LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS second_event_date FROM base)) SELECT APPROX_QUANTILES(date_diff_day, 100)[OFFSET(25)] AS percentile_25, APPROX_QUANTILES(date_diff_day, 100)[OFFSET(50)] AS percentile_50, APPROX_QUANTILES(date_diff_day, 100)[OFFSET(75)] AS percentile_75, MAX(date_diff_day) AS percentile_100, AVG(date_diff_day) AS average FROM (SELECT DATE_DIFF(second_event_date, event_date, DAY) AS date_diff_day FROM second_event_data)유저별로 로그인을 한 시점을 ROW_NUMBER()로 카운트했다. 또한, second_event_date(다음 로그인 시점)이 NULL인 경우는 이탈 유저이다. 그런데, 4분위 수를 계산하려면, 해당 값을 채워야했다. 2099-12-31로 하려고 했으나, 너무 큰 값을 채워버리면, 4분위 수 검증이 정확하지 않게 되기 때문에 (mid와 avg값이 오른쪽으로 치우쳐버리는 현상이 발생할 수 있다.) second_event_date의 max값을 구해서, 2023-01-20을 채워주었다.Approx_quantiles 함수는 백분위로 나눌 경우, 각 근사치의 최대값을 나타내는 함수이다. 중위값에 해당하는 값들 중 가장 큰 값은 39일이다. 이번에는, 해당 범위에 속하는 값들이 몇개가 있는지 확인해보겠다.SELECT COUNTIF(date_diff_day <= 19) AS count_up_to_25, COUNTIF(date_diff_day > 19 AND date_diff_day <= 39) AS count_25_to_50, COUNTIF(date_diff_day > 39 AND date_diff_day <= 66) AS count_50_to_75, COUNTIF(date_diff_day > 66 AND date_diff_day <= 109) AS count_75_to_100 FROM temp데이터가 1분위, 2분위에 몰려있다. 따라서, 40일 을 기준점으로 삼아야겠다.2022년 12월 19일 이후 ~ (신규유저)2022년 10월 3일 이후 ~ 2022년 12월 19일 이전, 10월 3일 이후부터 다음 접속 시간이 40일 이전인 경우 (기존유저)2022년 10월 3일 이후로부터 40일 이후로 접속한 유저(복귀유저)2022년 10월 3일 이후로부터 40일 이후로도 접속 이력이 없는 경우 (이탈 유저)3. 다음 접속일까지의 걸린 일 수 기반, 유저 분류-- 유저별, 첫번째 로그인 후, 다음 로그인하기 걸린 시간을 4분위 수로 계산 -- 25% | 50% | 75% | 100% -- 로그인_이벤트: click_login -- event_date, event_timestamp, event_name, -- 중간테이블 -- 유저별 로그인을 한 시점을 ROW_NUMBER()로 카운트하기 -- 유저별 첫번째 로그인을 한 시점 구하기 MIN(event_date) OVER() -- second_event_date가 NULL인 경우는 이탈 유저임. -- 그런데, 4분위 수를 계산하려면, MAX(second_event_date) 값을 구하고, NULL을 잠시 해당 값으로 채워놔야함. -- 그 이유는 너무 큰 값으로 채워버리면, 4분위 수 검증이 정확하지 않기 때문임 (mid값과 avg값이 오른쪽으로 치워쳐버리는 현상이 발생할 수 있음) max_event_date: 2023-01-20 WITH base AS (SELECT event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_timestamp, user_pseudo_id, event_name, ROW_NUMBER() OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS login_rn FROM advanced.app_logs WHERE event_name = 'click_login' AND event_date > '2022-10-03' QUALIFY login_rn < 3) , second_event_data AS (SELECT DISTINCT event_date, event_timestamp, user_pseudo_id, event_name, login_rn, IF(second_event_date IS NULL, '2099-01-20', second_event_date) AS second_event_date FROM (SELECT *, LEAD(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date) AS second_event_date FROM base)) -- 접속 데이터 기반, 신규, 기존, 복귀, 이탈 구분 , user_type_data AS (SELECT event_date, second_event_date, user_pseudo_id, DATE_DIFF(second_event_date, event_date, DAY) AS comeback_day, CASE WHEN event_date >= DATE('2022-12-19') THEN '신규 유저' WHEN event_date >= DATE('2022-10-03') AND second_event_date <= DATE_ADD(event_date, INTERVAL 40 DAY) THEN '기존 유저' WHEN event_date >= DATE('2022-10-03') AND second_event_date > DATE_ADD(event_date, INTERVAL 40 DAY) AND second_event_date != DATE('2099-01-20') THEN '복귀 유저' WHEN event_date >= DATE('2022-10-03') AND second_event_date = DATE('2099-01-20') THEN '이탈 유저' ELSE NULL -- 예외 처리 END AS user_type FROM second_event_data) 4. 각 유저 타입별 리텐션 계산기존 유저-- 일자별 리텐션 계산 (기존 유저) , analysis_current AS (SELECT diff_of_day, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM (SELECT user_pseudo_id, MIN(event_date) OVER (PARTITION BY user_pseudo_id) AS first_day, event_date, comeback_day as diff_of_day FROM user_type_data WHERE user_type = '기존 유저' ORDER BY event_date, second_event_date) GROUP BY 1) SELECT diff_of_day, user_cnt, first_user_cnt, ROUND(SAFE_DIVIDE(user_cnt, first_user_cnt), 3) AS retention_day_rate FROM (SELECT diff_of_day, user_cnt, FIRST_VALUE(user_cnt) OVER (ORDER BY diff_of_day) AS first_user_cnt FROM analysis_current)복귀 유저신규 유저이탈 유저리텐션이 평평하게 안나오네요... 뭔가 단단히 잘못된것 같습니다.. 

리텐션 SQL 쿼리 작성하기, Weekly와 Monthly 쿼리를 작성한 부분을 게시판에 올립니다.-- Weekly 리텐션 작성하기. 마지막 부분 , analysis AS (SELECT diff_of_week, user_cnt, FIRST_VALUE(user_cnt) OVER (ORDER BY diff_of_week) AS first_user_cnt FROM (SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_date_and_diff GROUP BY 1)) SELECT diff_of_week, user_cnt, ROUND(SAFE_DIVIDE(user_cnt, first_user_cnt), 3) AS retention_week_rate FROM analysis ORDER BY 1;-- 월별 리텐션 계산 WITH base AS ( SELECT DISTINCT user_pseudo_id, event_name, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, FROM advanced.app_logs WHERE event_date BETWEEN '2022-08-01' AND '2022-11-03' ), first_date_and_diff AS ( SELECT *, DATE_DIFf(event_month, first_month, MONTH) AS diff_of_month FROM ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), MONTH) AS first_month, DATE_TRUNC(event_date, MONTH) AS event_month FROM base ) ), analysis AS ( SELECT diff_of_month, user_cnt, FIRST_VALUE(user_cnt) OVER(ORDER BY diff_of_month) AS first_user_cnt FROM ( SELECT diff_of_month, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_date_and_diff GROUP BY 1 ) ) SELECT diff_of_month, user_cnt, ROUND(SAFE_DIVIDE(user_cnt, first_user_cnt), 3) AS retention_month_rate FROM analysis

강의 내용을 똑같이 따라했는데 'basic.pokemon'에서 오류가 떠요ㅠㅠ 제가 놓친게 있을까요?

윈도우 사용자입니다. 첨부파일을 다운로드 받았는데, 압축파일 풀기를 하면 아래와 같이 오류 메시지가 나오는데요. 어떻게 해결하면 좋을까요?

안녕하세요. 저는 이번에 마지막 문제를 응용해서, 퍼널별로 유저들의 새로운 세션 시작 횟수의 총합을 계산해보았습니다.[결과 그래프]새로운 세션 시작 기준: 이전 세션 시간 대비 20초 이상이 지나면, 새로운 세션을 활성화했다고 가정 (강의 내용과 동일)첫번째 강의에서 배운, UNNEST 문법과 PIVOT 을 하는 방법을 활용해서, event_params에 있는 firebase_screen의 string_value 값을 새로운 열인 firebase_screen 이라고 만듭니다. 전체 데이터를 조회하면, 쿼리 비용이 많이 들기 때문에, where 조건 절로 값을 작게 명시해줍니다.WITH base AS ( SELECT event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_timestamp, event_name, user_pseudo_id, MAX(IF(ep.key = 'firebase_screen', ep.value.string_value, NULL)) AS firebase_screen FROM advanced.app_logs CROSS JOIN UNNEST(event_params) AS ep WHERE event_date = '2022-08-18' AND user_pseudo_id = '5464646449.4088767327' GROUP BY ALL )LAG() 함수를 사용하여, 이전 날짜 값을 가져옵니다. 이 때, 퍼널별로 구해야하기 때문에, PARTITION BY에 firebase_screen 을 써줍니다. 그 후, DATETIMEDIFF 함수를 사용해서, 현재값과 이전값의 차이를 계산합니다.WITH base AS ( SELECT event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_timestamp, event_name, user_pseudo_id, MAX(IF(ep.key = 'firebase_screen', ep.value.string_value, NULL)) AS firebase_screen FROM advanced.app_logs CROSS JOIN UNNEST(event_params) AS ep WHERE event_date = '2022-08-18' AND user_pseudo_id = '5464646449.4088767327' GROUP BY ALL ), diff_funnel_time AS ( SELECT *, DATETIME_DIFF(event_timestamp, prev_event_timestamp, SECOND) AS second_diff FROM ( SELECT *, LAG(event_timestamp, 1) OVER(PARTITION BY firebase_screen ORDER BY event_timestamp) AS prev_event_timestamp FROM base ) ) SELECT * FROM diff_funnel_time3. ROW_NUMBER() 함수를 사용해서, 퍼널별로 순서를 매깁니다. 그 후, second_diff 의 값이 NULL인 경우는 해당 퍼널의 첫 시작 위치를 가리키므로 1을 넣어주고, rn > 1이고 second_diff >= 20인 경우는 1을 넣어줍니다. 이 때 funnel_per_session_start 컬럼은 퍼널별로 새로운 세션이 시작했는지 여부를 가리킵니다. , funnel_start AS ( SELECT *, CASE WHEN second_diff IS NULL THEN 1 WHEN rn > 1 AND second_diff >= 20 THEN 1 ELSE 0 END AS funnel_per_session_start FROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY firebase_screen ORDER BY event_timestamp) AS rn FROM diff_funnel_time ) )이제, 퍼널별로 세션 시작 여부를 SUM()하고, GROUP BY를 해줍니다.SELECT firebase_screen, SUM(funnel_per_session_start) AS funnel_per_session_start_cnt FROM funnel_start GROUP BY ALL ORDER BY 2 DESC;WHERE 조건절을 주석처리하고, 전체 데이터에 대해서, 집계해봅니다. WITH base AS ( SELECT event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_timestamp, event_name, user_pseudo_id, MAX(IF(ep.key = 'firebase_screen', ep.value.string_value, NULL)) AS firebase_screen FROM advanced.app_logs CROSS JOIN UNNEST(event_params) AS ep -- WHERE -- event_date = '2022-08-18' -- AND user_pseudo_id = '5464646449.4088767327' GROUP BY ALL ), diff_funnel_time AS ( SELECT *, DATETIME_DIFF(event_timestamp, prev_event_timestamp, SECOND) AS second_diff FROM ( SELECT *, LAG(event_timestamp, 1) OVER(PARTITION BY firebase_screen ORDER BY event_timestamp) AS prev_event_timestamp FROM base ) ) , funnel_start AS ( SELECT *, CASE WHEN second_diff IS NULL THEN 1 WHEN rn > 1 AND second_diff >= 20 THEN 1 ELSE 0 END AS funnel_per_session_start FROM ( SELECT *, ROW_NUMBER() OVER(PARTITION BY firebase_screen ORDER BY event_timestamp) AS rn FROM diff_funnel_time ) ) SELECT firebase_screen, SUM(funnel_per_session_start) AS funnel_per_session_start_cnt FROM funnel_start GROUP BY ALL ORDER BY 2 DESC;            

안녕하세요. 강의를 잘 듣고 있습니다.다름이 아니라, 연습문제를 모두 풀고 나서 윈도우함수 강의를 듣는 과정에서, default에 대해 궁금한 점이 생겼습니다. 정확히, 계산을 해야할 경우, 중복된 데이터가 있는 경우를 고려해서, ROWS BETWEEN UNBOUNDED PRECEDINIG AND CURRENT ROW 라고 프레임의 범위를 정확하게 명시를 하는 것이 좋을 것 같다. 라는 생각이 들었습니다.그 이유는 다음과 같습니다.강의에서 말씀해주신대로, 구글 빅쿼리는 default 값이 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 라고 되어있는데요,-- 4) -- 누적 쿼리: 과거의 시간(UNBOUNDED PRECEDING)부터 current row까지 SELECT *, SUM(query_cnt) OVER(PARTITION BY user ORDER BY query_date) AS cumulative_sum SUM(query_cnt) OVER(PARTITION BY user ORDER BY query_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cumulative_sum2 FROM ( SELECT query_date, team, user, COUNT(user) AS query_cnt FROM advanced.query_logs GROUP BY ALL ) -- QUALIFY cumulative_sum != cumulative_sum2 ORDER BY user, query_date문득, default값이 RANGE BETWEEN UNBOUND PRECEDING AND CURRENT ROW 라면, 왜 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 와 같은 값을 가질까? 다른 값을 가지는 경우도 있지 않을까? 하는 의문이 들었습니다.예제에서는, GROUP BY ALL을 했기 때문에, 중복 데이터가 있어도, query_cnt로 집계가 된 상태에서, 윈도우 함수를 실행하다보니, QUALIFY로 조건절 검증을 수행해도, != 를 만족하는 데이터가 없었던 것 같았습니다.그래서, 1번 예제와 4번 예제를 결합해서, 다음과 같이 검증을 수행해보았습니다.-- INSERT INTO my_sess.query_logs (user, team, query_date) -- VALUES ('샘', 'Data Science', '2024-04-24'); SELECT *, -- 시간의 흐름에 따라, 일자별 유저가 실행한 누적 총 쿼리 수 SUM(total_query_cnt) OVER(PARTITION BY user ORDER BY query_date) AS cumulative_total_sum, SUM(total_query_cnt) OVER(PARTITION BY user ORDER BY query_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cumulative_total_sum2 FROM ( SELECT *, -- 사용자별 시간의 흐름에 따라 쿼리를 실행한 총 횟수: total_query_cnt COUNT(query_date) OVER(PARTITION BY user) AS total_query_cnt FROM my_sess.query_logs ) -- QUALIFY cumulative_total_sum != cumulative_total_sum2 ORDER BY user, query_date결과는 다음과 같습니다.중복데이터가 있을 경우, RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW는 다 합쳐서 하나로 집계해서 결과값을 내놓는 것으로 보입니다.QUALIFY 함수를 적용했을 때cumulative_total_sum = cumulative_total_sum2 인 경우데이터 중복이 없을 경우에는, 같은 값이 나옵니다.

맥북 크롬 환경에서 강의 수강하고 있는데 소리만 들리고 강의 화면이 검정 화면으로만 나옵니다. 혹시 저만 그런걸까요..??

안녕하세요. 이어서, 윈도우 함수에 대해서 잘 듣고 있습니다.Bigquery PDF파일의 P.229페이지를 보면, LAST_VALUE 에 대해서, 쿼리 값이 있는데요, LAST_VALUE가 각 파티션을 나눈 user_id의 마지막 값(1004의 경우, 8, 2112의 경우 7, 3912의 경우 4)를 가져오려면, UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 값이 들어가야 합니다.그 이유가, 해당 FRAME이 따로 정의되어있지 않으면, 다음과 같은 값이 나옵니다.섹션 2-4 윈도우 함수 탐색 함수 연습 문제에서, FIRST_VALUE, LAST_VALUE로도 한번 쿼리 작성을 해보라는 연습을 해보라고 하셔서, 연습하는 도중에 발견하게 되었습니다.이번에는 UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 을 추가해보겠습니다.

안녕하세요. 빅쿼리를 좀 더 공부하고 싶어, 강의를 결제하게 되었습니다.다름이 아니라, app_logs_temp 데이터를 강의에서 알려준대로, upload 하고 테이블을 만들었을 떄는 정상적으로, 잘 표시가 되는데요, 문제는 event_date 를 기준으로 (날짜 기반 파티셔닝)을 했을 때, 데이터가 0B가 되는 문제가 발생합니다!Array, Struct 문제에서 4번 문제를 풀때, "데이터를 표시할 수 없다" 라는 말이 있어서, 왜 이럴까.. 하다가, 발견하게 되었어요..저는 이미 예전에 빅쿼리를 사용해본 적이 있어서, billing account 계정이 모두 연결된 상태이구요. chatgpt 말로는 이 방법도 안된다면, 빈 파티셔닝 테이블 만들어 놓고 INSERT INTO로 하나하나 데이터 넣으라는데... 예전에 프로젝트 할 때, 이 방법으로 했다가 돈이 꽤 나와서요.. 어떻게 해야할까요? 

안녕하세요. where에 조건을 걸기 전에 조인하고 한번 해봤는데 결과 갯수가 차이가 있습니다. 어떤 부분 때문에 이런 차이가 발생할까요?

카일님의 강의 잘 듣고 있습니다!2가지 질문이 있습니다!1번 질문) 카일님이 강의를 하시면서 주석처리를 되게 빠르게 실행하시는 것 같으신데, 혹시 팁을 공유해주실 수 있으실까요?-- 를 매번 입력하시는 것인가요?!2번 질문)5-6강의 11분 49초에서 쿼리를 빠르게 주석처리하기 위해서 앞에서 true인 1=1을 넣고, and쓰고 빠르게 주석처리..이 부분이 이해가 안됩니다.. 1=1을 넣는 것과 and에 주석처리를 거는 것과 무슨 연관이 있는 건가요?좋은 강의 늘 감사합니다!

카일님~혹시 5번 문제의 '이후'가 사전적으로는 기준이 되는 때도 포함이 되어서 >=로 작성이 되어야 할 것 같은데,강의에서는 >로 작성하셨더라구요.. 혹시 이렇게 작성하신 다른 이유가 있으신지 궁금합니다..!감사합니다 :)

카일님 안녕하세요 :)4-7 3번 문제에서 BETWEEN을 사용해주셨는데mysql에서의 BETWEEN 범위는 이상, 이하라고 하는데 혹시 bigquery는 그 포함 관계가 다른걸까요?301에서 500 사이면 BETWEEN 301 AND 500 이어야 할 것 같은데 300으로 작성하신 이유가 궁금합니다.나름대로 검증해보려고 total=301인 데이터를 뽑아보려했는데 pokemon 데이터에는 포함 안되어 있더라구요..ㅎㅎㅠ그리고 제가 3일 정도 뒤에 갑작스레 SQL 코딩테스트를 보게 되어 벼락치기를 해야하는 상황인데카일님의 SQL 개념+문풀 JOIN까지 듣고 프로그래머스 고득점 Kit로 문풀을 하면될지..시간이 넘 촉박해서 다 할 수 있을지는 모르겠는데 혹시 좀더 효율적인 공부 방향이나 팁이 있다면 추천 부탁드려도 될까요?ㅠㅠ항상 선한 영향력 감사합니다!!

강의 너무 잘 듣고 있습니다.혹시 활용편은 언제쯤 출시될 예정일까요?

안녕하세요 카일님~battle 데이터를 업로드하고 말씀해주신 설정을 똑같이 적용했는데미리보기에서 데이터가 보이지 않고, 쿼리의 FROM으로 불러와도 '표시할 데이터가 없습니다'라고 뜹니다혹시 관련해서 도움을 구할 수 있을까요?ㅠㅠ그리고 강의 너무너무 잘 보고 있습니다.. 최곱니다 너무 감사드려요ㅎㅎ (해결 완료)아래 게시글에서 '빌링 어카운트(결제 계좌)' 연결 후에 문제 해결되셨다고 하셨습니다.저는 '엇? 나는 지금 결제 계좌 연결되어있는데..?'라고 잠시 생각했으나다시 되짚어보니 제가 basic 데이터셋을 초반에 만들고, 그 이후에 결제 계좌를 연결했을 수도 있을 것 같아요그래서 저는 basic2 데이터셋을 새로 생성해서 battle 테이블을 생성해보니 정상적으로 진행되는 것을 확인했습니다!요약하면 '결제 계좌 연결 => 데이터셋(basic) 생성 => battle 테이블 생성' 순서가 반드시 지켜져야오류없이 진행되는 것 같습니다ㅠㅠ 원인을 알게 되어 정말 다행이고, 공유해주셔서 감사합니다 :)https://www.inflearn.com/questions/1250442/battle-%ED%85%8C%EC%9D%B4%EB%B8%94-%ED%98%95%EC%84%B1%ED%95%A0-%EB%95%8C-%EC%A0%9C%EA%B0%80-%EC%96%B4%EB%96%A4-%EC%8B%A4%EC%88%98%EB%A5%BC-%ED%96%88%EC%9D%84%EA%B9%8C%EC%9A%94

질문 드렸던 이전 게시글▶ https://www.inflearn.com/questions/1229720/pokemon-%ED%85%8C%EC%9D%B4%EB%B8%94%EC%9D%84-%EC%83%9D%EC%84%B1%ED%95%98%EA%B3%A0%EC%9E%90-%ED%95%98%EB%8A%94%EB%8D%B0-%EB%9C%A8%EB%8A%94-%EC%98%A4%EB%A5%98?re_comment_id=349352 =구글 드라이브에 파일을 업로드 한 후 공유 드립니다.https://drive.google.com/file/d/1Z8y2eJSlwfYEexaxyAan7Rt3xPrJtznE/view?usp=sharing 

안녕하세요. 수업 유익하게 잘 듣고 있습니다!  Espanso를 다운받아서 설정해봤는데요! 텍스트 편집기에서 수정까지 되었고, espanso 프로그램에서 open search bar 를 눌러봤을 때 첨부드린 이미지처럼 :sql 이 잘 들어가 있습니다.  그런데 :sql 과 같은 trigger 단어를 입력해도 변하지 않아서 어떤 다른 해결 방법이 있을지 문의드립니다.혹시 espanso의 설정 수정까지는 잘 되었으나, espanso가 어떤 권한 문제로 적용이 안될 수도 있나요? 추가로 시도해볼만한 방법이 있다면 안내 부탁드립니다. 감사합니다!

활용편 언제 나오나요급합니다.... 빨리 내놓으십쇼..유료로 내주셔도 긁겠습니다