안녕하세요 강사님, 더미데이터파일 수정본으로 새로 올려주실 수 있는지 여쭙고 싶습니다. 오라클db와 문법에 차이가 있는 파일이 그대로 업로드 되어 있는게 당황스러워요. 웬만하면 강의 영상으로 해결하려 했는데 강사님 하시는 걸 보고 똑같이 따라해도  8행부터 6236행까지 쭉 오류가 뜹니다.    

강의 잘보고 있습니다. Index 부분이 중요하다고 하셨는데 조금 헷갈리네요;; 1) SELECT * FROM sys.indexes WHERE object_id = object_id('accounts'); 의 결과 중 index_id 가 (0 = HEAP) (1 = CLUSTERED) (2 <= NONCLUSTERED) 인것같고 CLUSTERED INDEX를 사용하면 (0 = HEAP)대신 (1 = CLUSTERED) NON CLUSTERED INDEX라면 (1 = CLUSTERED)대신 (0 = HEAP)가 사용되는 것 같습니다.   2) DBCC IND('GameDB', 'accounts', N); N에 index_id를 넣어주게 되는데 CLUSTERED INDEX를 사용하여 index_id가 1부터 시작하게 되었을때도 0을 넣었을때 실행이 됩니다. 반대로 NON CLUSTERED INDEX일때 1을 넣어도 실행이 되는데 그냥 조회용인가요? 결과에 의미가 있나요?   3) DBCC IND('GameDB', 'accounts', 0); 실행시 첫 행의 의미는 어떤건가요?   4) NON CLUSTERED ± CLUESTERED INDEX Page Type의 [ 1은 Data Type이니까 RID를 통해 Heap Table에서 직접 값을 가져오기 ] [ 2는 Index Type으로 키를.. 값이..  Leaf에 실제 값들이 있고 그 값들의 키의 범위를 루트가 가지고 있다고 보면 될까요? => CLUSTERED에 실제 값이 있고 그 키를 가진 NONCLUSTERED페이지 ] (CLUSTERED가 있다면 모든 NONCLUSTERED는 CLUSTERED를 참조)   5) 그냥 CLUSTERED INDEX는 값들이 키순으로 정렬되어 사용되구요   6) 실제로 사용할때 한 데이터에서 INDEX를 많이 생성해서 사용하나요? 아니면 목적에 맞는 INDEX만 생성해서 사용하게되나요?   인덱스에 클러스터드에 구조까지 이해하려니까 좀 어려웠지만 일단 생각해보고 이해한거 정리하고 하면서 질문드려봅니다ㅜ

을 찾아보는데   SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY yearID ORDER BY HR DESC) AS ranking FROM batting ) AS yearTableWHERE ranking = 1ORDER BY yearID DESC;   FROM 이후에 AS로 이름을 지어주지 않으니 오류가 나는데 이름이 꼭 필요한가요?

join할 데이터베이스 양쪽 다 데이터가 많다면 Hash도 비용이 많이들어 효율이 낮아지는게 아닌가요? 만약 이럴땐 어떤 조인을 사용해야 할까요? NL을 사용하면 엄청난 비효율일 것 같고 Merge를 사용하기엔 데이터가 너무 많고 이래도 그냥 Hash를 사용하는것이 셋중에서 더 좋은 방법인가요?

INDEX를 설정해 준다는건..   데이터가 삽입될때 트리가 적당한 위치에 데이터를 저장하고   [ 트리의 루트에서 '왼오왼왼오'의 방향으로 가면 데이터가 있다. ]   라고 말하는 것과 비슷한가요?

1. CLUSTERED 는 영한 사전처럼 순서대로 저장된다고 하셨는데 그러면 DB에 INSERT 하는 순서대로 저장되는건가요? 2. NON-CLUSTERED 를 사용하는 이유르 정확하게 모르겠습니다. accountName을 NON-CLUSTERED INDEX로 만들었는데 보통 닉네임을 정할때 중복없이 생성하게 되는데 이걸 색인으로 만들면 특정 이름을 찾는데에 모든 플레이어들의 이름을 다 비교하는게 아닌가요? 만약 그렇게 되면 색인을 넣든 안넣든 똑같은게 아닌가요? 예를들어서 플레이어를 찾을 때 [찾고싶은 플레이어 이름 = '플레이어 이름'] 이런식으로 찾는다 했을 때 굳이 색인이 필요한지 색인을 안하고 [찾고싶은 플레이어 이름 = '플레이어 이름']  이런식으로 찾을 수는 없는건가요? 아니면 색인을 넣어줘야지 위처럼 찾는 기능이 가능한건가요?

안녕하세요, 강의 잘 듣고 있습니다 Primary Key 지정할 때 Unique와 Not Null  두가지가 중요하다고 말씀해 주셨는데요 1. 레코드 최대 수가 int 형 범위 이내이면 굳이 Primary Key 선정에 대해 고민을 안하고 모든 테이블 Primary Key를  id (int형 자동증가)로 설정해도 되나요? 2. 실무에서 id(int 형 자동증가) 로 쓰는 경우가 많은 가요? 3. 수강신청시스템의 경우 학번으로 primary key 지정 vs id(int형 자동증가) 지정 어떤 장단점이 있는지 궁금합니다. 감사합니다!

LAST_VALUE(salary) //salary의 마지막 값을 추출 OVER ( PARTITION BY playerID //playerid로 묶고 ORDER BY salary DESC //값이 큰 순서대로 정렬 ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) //현재 줄부터 동일한 palyerID의 마지막 줄까지 범위를 지정 이렇게 해서 정렬 순서대로 가장 마지막의 값이 가장 작은 값이니까 가장 작은 값이 뽑혀오는 것까지는 이해되는데요 왜 ORDER BY로 큰 순서대로 정렬했는데 반대로 뒤집어져서 작은 숫자부터 출력되는지 이해가 안가요..

안녕하세요! 좋은 강의 잘 듣고 있습니다. 다름이 아니라 질문이 있어 글을 남깁니다. 이미 User.js에서 age: Number로 설정해두었기 때문에 숫자 외의 것이 들어온다면 catch문에서 제대로 에러 처리가 될 것 같은데, 따로 라우트 내에서 age가 숫자인지 아닌지를 다시 체크하는 이유가 궁금합니다.  감사합니다!

[실전] 크롤링과 데이터베이스 - 크롤링 코드 작성 시작 강의 6분 58초 내용입니다 에서  실행을 할 때 오류없이 카테고리 ALL 내용은 카테고리만 출력을 하고, 그다음 카테고리들 부터는 카테고리와 서브카테고리를 잘 출력을 합니다. 다른 카테고리들(ex패션의류 신발/잡화 등)은 서브카테고리들(브랜드 여성의류 등)이 있어서 sub_categories = soup.select('div.navi.group ul li > a') 통해서 서브카테고리들을 가져올 수 있는데  ALL (메인)카테고리에서는 서브카테고리에 해당하는 내용이 없어서 크롤링을 할 때 빈값을 가져오고 그러면, 출력을 할 때(sub_category.get_text()을 사용할 때) 빈 값이니까 오류가 나야 하는거 아닌가요?

수업자료를 다운받아서 압축을 풀려고 하는데, 압축풀때 오류가 나는것 같아요. 확인 부탁드려도 될런지요?

UNION강의 4:30초에서 커리어 평균 연봉이 3000000 이상 "이거나" 12월에 태어난 선수를 구할 때 WHERE birthMonth = 12를 추가해주면 된다고 하셨는데 이 경우  커리어 평균 연봉이 3000000 이상 "이고" 12월에 태어난 선수를 구한 것 아닌가요?

안녕하세요 데이터베이스 인덱스 부분 강의를 듣던 중 궁금한 점이 생겨 질문드리게 되었습니다. 강의에서 직업이 5종류밖에 없다면 class 에 인덱스를 거는 것은 좋지 않다고 하셨는데 질문1) 여기서 좋지 않다는 것은 속도 향상이 있긴하나 효과가 적을뿐만 아니라 인덱스 자체의 크기(용량)이 커지기 때문이라고 이해하면 될까요? 질문2) 만약 직업별로 검색을 많이 하는 상황을 가정한다면 인덱스를 사용하는 것이 좋을까요? 읽어주셔서 감사합니다!

안녕하세요 Q1) 지금까지 이음동의어로 생각해왔는데 REDO = ROLL FORWARD UNDO = ROLL BACK 강의 마지막 결론에서 정리해주신 내용을 보니 또 다른 의미인 것 같아서 살짝 아리송 하네요 REDO 와 UNDO는 발자취(LOG)라고 보면  ROLL FORWARD나 ROLL BACK은 그 발자취를 따라 가는 행위를 말하는건가요? 마지막 질문으로 Part5 DB를 끝내봅니다 ㅎㅎ 감사합니다.

안녕하세요. 최근에 강의를 사서 매우 만족하며 듣고 있습니다. 들으면서 궁금한 점이 있어서 질문좀 드립니다. 예를 들어 학년과 반 테이블이 있다면, 제가 SpringJPA 를 공부하면서 배우기로는 한 학년에 여러 반이 존재하고, 한 반은 여러 학년에 존재할 수 있으므로 서로 1 : N 관계인 M : N 관계가 형성이 되는데요. 근데 이 강의를 접하고 나서는 굳이  중간 테이블을 하나 만들면서까지 M : N 관계를 고집하지 않아도 될 것 같더라구요. 예를들어 한 학년에는 여러 반이 존재하니,  학년 테이블과 반 테이블을 1 : N 관계로 설정 하고,  이번 강좌에서 한 것처럼 반 테이블에 외래키인 학년 ID 랑 반 ID를 같이 묶어서 PK로 만들면 PK가 중복될 일 없이 M : N 테이블 관계를 만든 것 처럼 역할을 할 수 있는것 같더라구요. 그래서 여기서부터 의문이 들었습니다. 실전에서는 M : N 관계라도 비즈니스 관계가 (예를 들면 이번 강의에서 "선생님" 이 "과목" 을 "개강하다." 처럼) 있는 것이 아니면 위에서 말한 학년 반 처럼 1 : N 으로 만들고 N 테이블 쪽에는 PK 를 묶어서 정의하나요? 그리고 이번 강의에서처럼 강사님처럼 "선생님" 이 "과목"을 "개강하다" 라는 문맥을 만들어서 비즈니스 관계를 찾는게 아직은 익숙하지가 않더라구요.  혹시 요구사항문을 보고 이런 것을 빨리 캐치하는 팁 같은것은 없을까요? 당연히 반복된 연습이 제일 최고인 것은 알지만 혹시나 싶어서 질문드려봅니다. 좋은 강의를 정말 좋은 가격에 만들어주셔서 너무 감사드립니다. 

안녕하세요 강의 9분부터 시작되는, DMBS 자체적으로 Non Clustered Index를 사용하지 않는 이유가 궁금해서 질문드립니다. Q1) 다른 수강생분들이 올린 질문도 참고를 했는데 SELECT * FROM TestOrders WHERE CustomerID = 'QUICK'; 다음과 같은 sql문을 실행했을 때 DBMS가 INDEX를 사용하지 않고 SCAN을 하는 이유가 실제로 힙 테이블 내에 page가 메모리에 적재되지 않아 역효과가 발생할 수 있기에 라고 Full scan을 하는게 더 낫다고 하셨습니다. 마치 OS 가상메모리에서 page fault 가 일어나는 현상과 비슷하다고 생각을 합니다. 여기까지는 이해가 됐습니다.  다만 full scan이 더 효율적일 수 있을까? 하는 의구심이 듭니다.  SELECT * FROM TestOrders WHERE CustomerID = 'QUICK'; 다음과 같은 sql문을 실행했을때 테이블의 데이터들도 인메모리 상태가 아니라면 물리 저장소에 접근후 메모리에 적재를 해야할텐데 과연 더 효율적일까 생각이 듭니다. 둘 다 메모리에 없다면 물리 저장소까지 다녀오는 건 비슷하다고 생각하는데 Full Scan이 조금 더 빠른건 Locality 때문인걸까요? Q2) 마지막 질문으로 Clustered Index와 비교해서 생각을 해보고싶습니다. Clustered Index는 Leaf Page가 곧 Data Page인데 이 Data Page도 메모리에 항상 적재되어 있을 것 같진 않습니다. 그럼에도 불구하고 Non Clustered Index보다 Select와 같은 Lookup이 빠른 이유는 Data Page내에 정렬된 데이터들과 이에따라 자연스레 형성된 Locality 때문인가요?

안녕하세요 :) Q1) Clustered Index 를 추가 한 뒤 Non Clustered Index의 변화를 살펴보면 PageID 값도 변하고 Heap Table이 사라짐에 따라 Heap RID도 변하게 됨을 확인했습니다. 궁금한 것은 강의 후반부 *18분 이후 내용입니다. Heap Table이 사라져도 Non Clustered Index를 사용해서 테이블에 저장된 데이터를 찾게 될텐데, 강의중 말씀하신 고유한 key 값이란 무엇인가요? UNIQUIFIER를 말씀하신걸까요? Q2-1)  Clustered Index를 추가하면 Non Clustered Index의 구조가 변하는 것은 확인을 했는데 이는 OrderID라는 공통 Index가 있어서 가능한 일 인 것 같습니다. 공통 Index가 없이 Clustered Index를 추가해도 구조에 변화가 생기게 되는지 궁금합니다. Q2-2) 이어서 엉뚱한 질문을 드리면 Non Clustered Index 추가시 매커니즘을 보면 Non Clustered Index를 통해 고유한 Key 값 얻기 -> 고유한 Key 값으로 Clustered Page에서 Lookup   이와 같은 매커니즘인데 Non Clustered Index를 통해 얻은 고유한 Key값이 Clustered Page에서 데이터를 Lookup할 때  SCAN 가 아닌 SEEK을 한다는 보장이 있을까요?  다른 표현으로(맞는 표현일지는 모르겠지만...) Key값이 Clustered Page에서 Index로서의 역할을 제대로 할 수 있는건가요? 직전의 질문과도 연관이 있어보이는데 제 질문의 요점은 Non Clustered Index의 결과물을 Clustered Index의 Lookup에서 재사용하는 그림인데, 두 Index는 정의시 지정한 컬럼이 다른데 호환이 가능한지 궁금하네요. 감사합니다~

Update with ObjectID를 하던 중 아래와 같은 에러가 발생하였습니다. 강의와 동일하게 수행하였다고 생각하는데 뭐가 문제 일까요?

안녕하세요! 항상 빠른 답변 감사드립니다! Clustered Index에 대해 DBCC IND에서 Leaf Page 번호 확인 후 DBCC PAGE 로 실제 정보가 어떻게 들어가 있는지 보려고 시도했는데 "DBCC 실행이 완료되었습니다. DBCC에서 오류 메세지를 출력하면 시스템 관리자에게 문의하십시오."가 뜹니다. Non-clustered 와 다르게 clustered 인덱스의 leaf page에 담겨 있는 실제 데이터는 이런 쿼리로 볼 수 없는 건가요??

요즘 ORM 기술이 핫한거 같은데 게임 개발 업계에서도 ORM이 핫한가요 ?