settings.py를 똑같이 작성하고, hands_on 경로에 있는 것도 잘 확인했는데, PRINT_SQL=1 py manage.py shell을 작성하면, -------------------------------- PRINT_SQL=1 : 'PRINT_SQL=1' 용어가 cmdlet, 함수, 스크립트 파일 또는 실행할 수 있는 프로그램 이름으로 인식되지 않습니다. 이름이 정확한지 확인하고 경로가 포함된 경우 경로가 올바른지 검증한 다음 다시 시도하십시오. 위치 줄:1 문자:1 + PRINT_SQL=1 + ~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (PRINT_SQL=1:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException ----------------------------------- 이렇게 에러가 납니다.. 그래서 좀 찾아보니까 ------------------- $env:PRINT_SQL=1 py manage.py shell ------------------- 이렇게 작성하면 된다고 하는데 맞을까요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요! 선생님 강의 잘 듣고 있습니다. 23:16초에서 "실무에서 이것이 왜 중요할까?" 부분이 잘 이해가 안가서 질문 드립니다. 제가 이해한 바로는 FROM users JOIN orders 와 FROM orders JOIN users 의 차이는 안에서 복제를 해서 전체 행의 수가 늘어나는지, 자식 테이블의 행 개수가 그대로 유지인지 이 차이이고, 결과물은 같다고 생각합니다. (inner join은 교집합이니깐) 그런데 지금 실무에서 이것이 왜 중요할까? 부분에서 <<집계함수인 COUNT(u.user_id)를 실행하면 어떻게 될까? 주문을 여러번 한 고객이 중복 계산되므로 전체 주문 수인 7이 나온다>>고 하셨는데 기준 테이블을 부모로 잡든 자식으로 잡든 결과는 똑같지 않나요? 제가 저 구문의 의도를 잘 파악하지못하여 질문 드립니다.
안녕하세요. 작년 필기 합격 후 바로 결제했었는데, 현생에 치여 이제서 다음 실기 시험을 준비하게 되었습니다. 다만 9월 21일 만료인데, 15분짜리 강의영상을 보는데 1시간이 넘게 걸리네요.. 이해안되어서 반복하고 따라하다보니.. 현생에 치여 하루에 두 어시간 밖에 할애를 못하고 있는데 21일전에 89강을 다 보는 것이 아무래도 무리인 것 같아서요. 최대한 시청해보겠지만 혹 약간 시간을 연장하여 여유 시간을 좀 더 주실 수 있을까요? 시간이 조급하다보니 영상보면서 예제도 실습못하고 스트레스만 쌓여가서 ㅜㅜ 미리 문의드립니다. 메일주소는 taurus8805@naver.com 입니다. 감사합니다.
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 강사님의 예제처럼 GROUP BY 와 ORDER BY 를 사용했습니다. 이때, 카테고리별 구매금액 정렬이 함수와 백틱을 사용했을 때 경우가 다르게 동작하는데 그 이유가 궁금합니다. 세종대왕 케이스를 확인해주시면 감사하겠습니다. 함수를 직접 사용하였을 때 백틱을 사용하였을 때
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 강의 연장 가능할까요? 바쁘시지만 연장해주시면 감사하겠습니다.
안녕하세요 강사님. 08-14 강의 도입부에서 FormView는 ModelForm클래스가 아닌 Form클래스에 대한 일반적인 패턴을 구현하는데 사용한다고 말씀 주셨고 코드에서도 db저장 로직을 직접 구현해 주셨는데요. FormView에서도 form_class를 ModelForm으로 지정하면 좀 더 간결한 것 같은데 혹시 FormView에서 ModelForm을 사용하면 안되는 이유가 있을까요? [코드 예시] ㄴ강의 내 #1. FormView 활용에 나오는 오른쪽 코드에서 form_class를 ModelForm으로 만들어 form_valid를 오버라이딩 하였습니다. class PostCreateView(FormView): form_class = PostForm template_name = "blog/post_new.html" success_url = "/admin/" def form_valid(self, form): form.save() return super(PostCreateView, self).form_valid(form)
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
문제2 : 쇼핑몰 매출 현황 파악하기 에서 '평균 주문 금액'을 구하는것에 질문이 있습니다. 제가 생각한 답은 SELECT SUM(price*quantity) , SUM(price*quantity)/COUNT(*), MAX(price), MIN(price) FROM order_stat; 이것인데, 강의에서는 AVG 를 이용해서 하셨는데, 혹시 실무에서는 어떻게 구할까요?
안녕하세요. 강의를 들으면서 잘 이해가 되지 않는 부분이 있어 질문 드립니다. 질문 드리고자 하는 부분은 "직원명 SMITH의 과거 소속 부서 정보를 구할 것"이라는 문제의 쿼리문인데요. 우선 제가 작성한 쿼리문은 아래와 같습니다. select a . ename , a . empno , b . deptno , c . dname , b . fromdate , b . todate from hr . emp a join hr . emp_dept_hist b on a . empno = b . empno join hr . dept c on a . deptno = c . deptno where a . ename = 'SMITH' ; 그리고 강사님께서 작성하신 쿼리문은 아래와 같구요. select a . ename , a . empno , b . deptno , c . dname , b . fromdate , b . todate from hr . emp a join hr . emp_dept_hist b on a . empno = b . empno join hr . dept c on b . deptno = c . deptno where a . ename = 'SMITH' ; 두 쿼리문의 차이는 join hr.dept c on 부분에서 "a.deptno = c.deptno"과 "b.deptno = c.deptno"입니다. 제 생각에는 위 두 쿼리문이 같은 결과를 뱉어야 할 것 같은데.. 아래 쿼리문 결과를 보면 dname 부분이 다르게 출력됩니다. 1) 제가 작성한 쿼리문 결과 2) 강사님이 작성하신 쿼리문 결과 제 짧은 지식으로는 두 결과가 동일해야 할 것 같은데, 제가 잘못 생각한 부분이 있다면 말씀 부탁드립니다 ㅠ
김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 46. GROUP BY - 그룹으로 묶기 강의 중 그룹으로 묶은 뒤 집계 함수를 사용한 컬럼을 기준으로 정렬하는 내용에 질문이 있습니다. ORDER BY에 총 구매 금액 이라는 alias로 지정한 컬럼명을 사용해도 되고, sum(price * quantity) 로 SELECT 절에서 사용한 집계함수를 다시 사용해서 정렬해도 된다고 설명해주셨습니다. 만약 집계함수를 사용했을 땐 계산을 또 해야하고, 컬럼명을 사용했을 땐 컬럼을 참조만 한다면 성능에 차이가 생기지 않을까라는 생각이 들었습니다. ORDER BY 절에 집계함수를 사용하는 것과 컬럼명을 사용하는 것의 동작 원리가 같은지, 성능상의 차이가 있는지 궁금합니다.
첫번쨰 dag 실행시 링크로 가쟈오는 csv 파일이 xml 파일로 읽어드리면서 에러로 띄우네요?? 도커에서 csv 파일을 읽을떄 에러메세지를 xml로 리턴하는거같은데 우선 csv 파일자체를 넣어서 하드코딩했습니다. 혹시 도커로 사용시 외부 파일받아올때 보안적인 부분에서 해제해야되는경우가있나요?
💡 질문하기 전에 먼저 확인해보세요! 답변을 기다리는 동안, 아래 항목들을 먼저 확인해보시면 문제가 해결될 수도 있어요. 강의 내용 다시 보기: 혹시 놓친 부분이 없는지 해당 챕터의 강의를 한 번 더 돌려보셨나요? 오타 및 들여쓰기 확인: 파이썬은 특히 들여쓰기에 민감해요. 코드에 오타나 잘못된 들여쓰기는 없는지 꼼꼼히 확인해주세요. 에러 메시지 검색: 빨간색 에러 메시지가 떴다면, 메시지 전체를 복사해서 구글에 그대로 붙여넣기 해보세요. 전 세계 개발자들이 비슷한 문제를 겪고 해결책을 공유해두었을 확률이 높습니다. Q&A 게시판 검색: 혹시 다른 분이 먼저 비슷한 질문을 올렸는지 게시판을 한번 살펴보는 것도 좋은 방법이에요.
안녕하세요 스승님! 질문드립니다! 데이터 정합성을 위한 확인 절차는 front, back, DB에서 3중으로 처리하는게 좋은가요? 아니면 애플리케이션 레이어에서 처리하는게 좋을까요? (3중으로 하면 처리가 빠르고 정확할 수 있다는 장점이 있지만 처리 조건이 변경되는 경우 3군데에서 모두 변경이 있어야한다는 점이 꽤 번거로울 것 같습니다...) 이후 설계에서 다뤄주시겠지만, 1:1 관계의 테이블로 연결된 두 테이블에서 FK에 UNIQUE 제약을 거는게 일반적인지도 궁금합니다. 매번 덕분에 성장하고있슴다! 감사합니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 대상 위치] 강의 영상: 03:00 지점 강의록: 6. CASE 문.pdf - CASE 문 기본2 - CASE 문과 사용 위치 [질문 내용] 안녕하세요, 영한님. 다음과 같이 ' SELECT 절에서 사용한 CASE 문을 그대로 복사-붙여넣기 해서 ORDER BY 절에서 사용(THEN 결과는 1, 2, 3으로 변경)' 하셨는데요(아래 코드. 방법1 ). ORDER BY CASE WHEN price >= 100000 THEN 1 WHEN price >= 30000 THEN 2 ELSE 3 END ASC 실습하던 중 아래 코드( 방법2 )와 같이 ' SELECT 절에서 정의한 컬럼 별칭( price_label )과 THEN 값('고가', '중가', 저가')을 이용' 해서 정렬할 수도 있겠다고 생각해서 시도해봤고, 실행이 성공하여 영한님 코드와 동일한 결과가 나왔습니다. ORDER BY CASE WHEN price_label = '고가' THEN 1 WHEN price_label = '중가' THEN 2 WHEN price_label = '저가' THEN 3 END ASC 이때 자바와 같은 프로그래밍 언어 입장에서 보면 방법2 의 경우가 ' SELECT 절의 CASE 문 로직이 바뀌더라도 ORDER BY 절의 CASE 문 로직은 변경할 필요가 없으므로' 유지보수성 측면에서 더 좋겠다고 판단했습니다. 그런데 다음과 같은 반론(?)도 생각나더라구요. (애플리케이션 로직과 달리) 쿼리 문은 엄청나게 길고 복잡해질 가능성이 적으므로, 그냥 방법1 처럼 복사-붙여넣기 해서 써도 무방하다. 오히려 ORDER BY 절의 CASE 문을 새롭게 작성하는 과정에서 오타가 발생하여 오류를 일으킬 위험이 존재하니, 그냥 방법1 처럼 복사-붙여넣기 해서 써도 무방하다. 간단한 쿼리의 경우 ORDER BY 절의 CASE 문을 새롭게 작성하는 데에 비교적 많은 시간이 소모되는 비효율성이 존재하니, 그냥 방법1 처럼 복사-붙여넣기 해서 써도 무방하다. 이에 대해서 영한님의 의견은 어디에 가까우신가 의견 여쭙고 싶어서 글 남깁니다!
