-- 높은 재귀(반복) 횟수를 허용하도록 설정-- (아래에서 생성할 더미 데이터의 개수와 맞춰서 작성하면 된다.)SET SESSION cte_max_recursion_depth = 1000000; -- 더미 데이터 삽입 쿼리INSERT INTO users (name, age)WITH RECURSIVE cte (n) AS( SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 1000000 -- 생성하고 싶은 더미 데이터의 개수)SELECT CONCAT('User', LPAD(n, 7, '0')), -- 'User' 다음에 7자리 숫자로 구성된 이름 생성 FLOOR(1 + RAND() * 1000) AS age -- 1부터 1000 사이의 랜덤 값으로 나이 생성FROM cte;-- 잘 생성됐는 지 확인SELECT COUNT(*) FROM users; SELECT n + 1 FROM cte WHERE n < 1000000 -- 생성하고 싶은 더미 데이터의 개수SELECT n + 1 이 먼저 실행되고 FROM cte WHERE n < 1000000 이부분이 실행되니까.n이 999999까지 실행되고 n + 1 =1000000 이니까 FROM cte WHERE n < 1000000이부분에 걸려서 1000000이 실행 안되는게 맞지 않나요?

 1.제가 비전공도 할수있는 데이터베이스강의를 듣고 이 강의를 듣고있는데요. user테이블에 name의 fk가 들어가는게 맞지 않나요? 빨간색 글씨로요. name id pk도 빨간색처럼 pk를 적어야 하지 않나요?아니면 name테이블과 name인덱스 테이블이 따로 있는건가요?2.인덱스가 새로운 테이블을 생성하는건가요?3.풀인덱스스캔 강의 질문있습니다.CREATE INDEX idx_name ON users (name); 이 구문이아래처럼 테이블을 미리 만드는건가요? 

사용자, 임무 한명의 사용자는 여러가지의 임무를 가진다. 한가자의 임무는 여러명의 사용자를 가진다. 예를들어 양치질하기는 a사용자,b사용자,c사용자로 등록할 수 있기 때문에 상품-주문테이블처럼(아래형식처럼) 테이블 분리되어야하지 않나요? 임무 no 임무명 임무설명 데드라인 1 청소하기 청소하기 1.27 2 빨래하기 청소하기 1.27 사용자-임무 no 임무명 (외래키) 사용자(외래키) 1 1 1 1 1 2  

주문할 때마다 배송 정보를 새로 입력하기 때문에 주문 정보 : 배송 정보 = 1 : 1인 건 이해했습니다. 그런데 만약 주문할 때마다 배송 정보를 기본적으로 새로 입력하기는 하지만, 이전에 사용했었던 배송지를 다시 불러오는 기능이 있고, 기본 배송지를 설정하는 기능도 있다고 하면이런 경우에도 여전히 1 : 1이라고 생각하면 될까요? 관계는 동일하고 불러오거나 기본 배송지 기능은 그냥 코드로 구현하면 되는 걸까요?

recovery() 를 스케줄로 구현한 부분에 있어서 궁금증이 있습니다.설명에도 언급 되었듯이 k8s 환경과 같이 scale-out 형태로 서비스를 제공하면 동시성 이슈가 발생될 것으로 예상되는데요.단순하게 하나의 unknown order 만 생성해서 테스트로 갈음하기에는 검증이 부족하다고 느껴지는데, 동시성 검증은 어떻게 진행하셨을까요?

만약 이렇게 색깔 컬럼에 RED 같은 걸 넣지 않고, #325645 를 위와 같이 중복해서 넣는다면, 이건 진짜 중복이라고 봐야 하나요? 진짜 중복이라는 생각은 드는데, #325645는 이미 특정 색을 지정하고 있어서 이것도 true, false처럼 생각해야 하나?라는 생각도 들고 뭔가 조금 헷갈려서 확인차 질문드립니다.

만약 응답해야 되는 데이터는 "많은" 데이터인데데이터베이스에서 조회할 때는 LIMIT, WHERE로 나눠서 가져오고 애플리케이션 로직에서 합쳐서 응답하는게 나은가요?아니면 네트워크를 여러번 타는 것 보다는 이런 경우에는 한번에 가져오는게 더 나을까요?상황에 따라 다르겠지만,, 참고할만한 지침같은게 있을까 싶어서 여쭤봅니다!

put과 delete두 메소드 자체에는 보안적으로 취약한 점은 없고수정과 삭제라는 기능적인 측면에서 보안적으로 위험할 수 있다고 이해하고 있는데 맞을까요?

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 연초라 시간남아서 이 강좌도 연장 부탁드릴게요 한번 더보게요

다음과 같이 웨어하우스에서 다운로드시 404에러가 나오며 다운로드가 되지 않고 있습니다. 주소상 문제는 아닌 것 같고, 웨어하우스 한번 확인해 주시면 좋을 것 같습니다. 감사합니다.

만약 주문 수량에 따라 재고량에 바로 반영된다는 기획이라고 가정한다면, 주문수량을 수정 할 때 재고량도 수정해야 하는 숨은 중복 이라는 생각이 듭니다. 이 경우에도 테이블을 분리 하는 것이 맞는 걸까요?

사용자 테이블 과 팔로우 테이블 과의 관계를 다대다 관계라고 할 수 있을까요?중간 테이블로 풀어내는 다대다 관계랑은 조금 다른 것 같아서 이런 경우에는 명칭이 어떻게 되는지 궁금합니다

안녕하세요. 강의 잘 듣고 있습니다. 입문자들은 역정규화보단 정석적인 방법대로 하는 게 좋다고 하셨는데, 실제 현업에서 오래 일을 하셨던 분들이라 해도 뭔가를 처음 설계할 땐 중복을 없애는 방식으로 설계하고, 실제로 성능 등에 문제가 생기면 그때 역정규화를 고려하나요? 역정규화 자체가 처음 설계 때는 잘 안 하는 건지 궁금합니다.

Choose Category의 UI를 보면 Create New라는 항목이 보입니다. 즉 내가 원하는 카테고리를 추가하는 기능이 있는 것으로 보이고, 내가 추가한다고 남에게도 그 항목이 보이면 안되므로, 혹은 기존의 카테고리의 아이콘이나 색깔을 바꾼다고 남에게도 적용되면 안되므로 categories 테이블에는 사용자의 FK값이 있어야 할것으로 판단됩니다. 이렇게 할 경우, tasks 테이블에서 category의 FK와 사용자의 FK를 받게 될텐데, 외래키로 받은 category에도 사용자의 FK가 포함되어 있어서 사용자 FK정보를 두 번 갖게 되는것 같습니다. 물론 task나 category에서 한 번 지정된 사용자가 변경되는 일은 없을 것으로 보이지만, 그래도 엄밀히 말하면 데이터가 중복이 되는 것이 아닌지 궁금합니다. 

강의 연장 가능할지 문의드립니다 !

이게 이제는 skip 으로는 안되나보네요..ㅎㅎ

강의에서 중간 테이블이, 1칸에 1개의 정보가 불가할 때라고 듣기도 했고N:M의 관계일때는 반드시 중간 테이블을 제작해야 한다고도 들었습니다.저 두 가지의 경우가 같은건지 궁금합니다.N:M 관계가 아닌데도 중간테이블이 만들어질 수도 있나요?

EXPLAIN ANALYZE SELECT * FROM users ORDER BY salary LIMIT 100; -> Limit: 100 row(s)  (cost=100569 rows=100) (actual time=338..338 rows=100 loops=1)    -> Sort: users.salary, limit input to 100 row(s) per chunk  (cost=100569 rows=996636) (actual time=338..338 rows=100 loops=1)        -> Table scan on users  (cost=100569 rows=996636) (actual time=0.0672..250 rows=1e+6 loops=1)        CREATE INDEX idx_salary ON users (salary); EXPLAIN ANALYZE SELECT * FROM users ORDER BY salary LIMIT 100; -> Limit: 100 row(s)  (cost=0.0918 rows=100) (actual time=0.0709..0.253 rows=100 loops=1)    -> Index scan on users using idx_salary  (cost=0.0918 rows=100) (actual time=0.0692..0.249 rows=100 loops=1)  여기서 질문이 있는데요. 인덱스를 salary에 적용한 이후에도 analyze이후 actual time이 인덱스가 없을때와 별차이가 없어 보이는데요. 이건 mysql의 실행계획 표시에 오류가 있는걸까요?실제로 실행 속도는 향상은 돼었습니다. 

SELECT e.emp_id , s.avg_salary , s.max_salary , s.min_salary FROM EMP e, (select emp_id, ROUND(AVG(annual_salary), 0) avg_salary, ROUND(MAX(annual_salary), 0) max_salary, ROUND(MIN(annual_salary), 0) min_salary from SALARY where emp_id BETWEEN 10001 and 10100 GROUP BY emp_id) s WHERE e.emp_id = s.emp_id; 처음에 답을 안 보고 제가 개선해본 쿼리인데,필터링 조건을 salary에 넣어주고, 이걸 조인해서(emp의 primary key) 나오는 결과인데 미세하게 더 빠르네요.!  정답 쿼리가 조금 더 느린 이유는 salary 테이블을 3번 접근해서 그런거 같은데(index를 활용하더라도) 맞는지 궁금합니다.

SELECT REGION, GATE, COUNT(*) AS cntFROM ENTRY_RECORDWHERE REGION <> ''GROUP BY REGION, GATE WITH ROLLUP; -- 414ms ROLLUP 사용법이 달라서 구글이나 지피티에 서칭을 해봤습니다. 저처럼 안 되시는 분이 많을 거 같아서 올립니다.