『개발자를 위한 인덱스 생성과 SQL 작성 노하우』

- 개발 현장에서 바로 통하는 인덱스 생성 및 쿼리 작성 노하우 제시
- 관리를 쉽게 하고 개발 생산성을 끌어올리는 쿼리 작성의 정석 '공정쿼리'
- 이론과 개념을 뛰어넘는 경험과 검증 기반의 DB 실무 노하우 전달
- 기초 모델링 개념을 녹여낸 실무 중심의 SQLP, SQLD 준비서
- DBGuide.net 최고 인기 연재를 책으로
- 비유와 이야기로 풀어내는 명쾌한 접근, 쿼리작성 문제로 재미있게 공부
- 개발자와 DB 전문가가 함께 볼 수 있는 DB 실무 가이드 북

개발자 입장에서 DB 인덱스 처리와 쿼리 작성 노하우를 명쾌하게 알려주는 책.
데이터와 데이터베이스(DB)의 중요성이 어느 때보다 강조되고 있다. 얼마 전까지만 해도 DB에 대한 깊은 이해는 튜너나 DBA의 영역처럼 여겨졌다. 하지만 데이터 시대의 도래와 함께 상황은 달라졌다. 개발자도 DB에 대한 폭넓은 이해가 요구되고 있다. 이 추세를 반영하듯 DB 및 SQL 튜닝 소개서들이 속속 출간되고 있다.

개발자 입장에서 DB 인덱스 처리와 쿼리 작성 노하우를 제대로 풀어낸, 볼 만한 책 한 권이 나왔다. 『개발자를 위한 인덱스 생성과 SQL 작성 노하우』가 바로 그 주인공. 이 책은 데이터 지식 포털인 DBgude.net에서 3년 이상 연재되면서 큰 인기를 모았던 내용을 재구성한 것이다.

'장보기를 잘하는 개발자가 쿼리도 잘 짠다'
『개발자를 위한 인덱스 생성과 SQL 작성 노하우』는 철저하게 개발자 중심으로 접근한 튜닝 가이드다. DB 전문가 대상의 이론이나 개념 중심의 튜닝에서 벗어나 코딩 시 헷갈리는 인덱스 지점을 어떻게 잡고, 실행계획(plan) 적용 방법을 그림과 비유로 흥미롭게 소개한다.

저자는 책에서 '개발자의 관심은 DB 이론이나 개념을 아는 데 있지 않다. 인덱스 포인트를 파악해 쿼리를 짜면 DB 속도는 물론 개발 생산성과 관리까지 한 번에 잡을 수 있다'고 소개하고 있다. 또한 '인덱스 포인트를 파악해 상식 선에서 접근해도 개발자 측면에서 SQL 튜닝은 충분히 잘할 수 있다'고 강조한다.

먼저 이 책의 인덱스 소개 방식이 눈길을 끈다. '인덱스 생성도'라는 그림이 그것이다. 개발자가 쿼리 작성 시 고민하게 되는 인덱스 생성 포인트를 설명할 때 계속 제시된다. 인덱스 생성도를 그려보면, 복잡한 쿼리 작성 시에도 인덱스 포인트를 정확하게 집어낼 수 있다. '인덱스 생성도'는 필자가 개발자 시절에 유독 헷갈리기만 했던 경험에서 나온 것이다. 개발자 입장에서 인덱스는 B의 핵심 개념임에도 어려워하는 사람이 많아서, 필자 스스로 이해했던 과정을 그림으로 도출한 것이 인덱스 생성도입니다.

쉽게 만나기 어려웠던 쿼리 작성 경험과 노하우도 눈에 띈다. 인덱스 생성 지점을 파악해 테이블 접근 순서(실행계획)에 따라 누구나 금방 알아보도록 작성한 쿼리를 이 책은 '공정쿼리'라고 소개한다. 반면 작성자 본인만 알 수 있는 쿼리를 '나쁜 쿼리'라고 한다. 나쁜 쿼리는 개발 생산성 저하뿐 아니라, 나중에 성능 및 관리 문제까지 야기할 수 있다.

\"명절 제수용품을 사려고 주부가 재래시장을 방문하는 예로써 알아보자. 물건을 어떤 순서(How)로 살지 미리 생각한 주부는 그렇지 않는 주부보다 쉽게 장보기를 마칠 수 있다. 개발자들이 작성하는 쿼리도 장보기의 과정과 별반 다르지 않다. '개발자로서 나는 똑같은 장소를 몇 번씩 왔다 갔다 하면서 장을 보고 있지는 않나?' 아니라고 자신 있게 답하려면, 쿼리 작성 시 어떤 경로로 장을 볼지 염두에 둬야 한다. 즉 사야 할 물건(What)뿐 아니라 어떤 순서(How)로 살 것인지에 대한 경로까지 쿼리에 포함해야 하는 것이다. 결국 잘 작성된 쿼리에는 실행계획(plan)과 인덱스 생성 위치(point)가 분명하게 드러난다. 이것이 바로 공정쿼리다. 공정쿼리는 결과 값(무엇)뿐 아니라 이걸 어떻게 보여줄 것인지를 방법(어떻게)까지 명확하게 드러낸 쿼리다.\"

데이터 시대 달라지는 개발자의 역할
DB 속도를 높이고 문제의 지점을 찾는 일은 DB 튜너 또는 DBA의 전담 영역으로 여겨질 때도 있었다. 하지만 시스템 개발 현장은 DBA나 튜너에게 전적으로 의존할 수 없는 것이 현실이다. 심지어 DB 전문가가 없는 곳도 있다.

이 책은 DB 전문가에게 의존하지 않으면서도 개발자 스스로 DB와 호흡을 맞추는 방법을 소개한다. DB에 익숙하지 않은 개발자 입장에서 접근했으므로 어렵지도, 개념적이지도 않다. 인덱스나 튜닝 등 총 37회에 걸쳐 물탱크 구조 생활 주변의 것들과 비유하면서 소개한다. 달력, 마방진, 60갑자 등을 간단한 쿼리로 직접 구현해 보기도 한다.

'데이터 모델링 기초 지식이 녹아 있는 책'
이 책은 DB의 구조, SQL의 기초, 데이터 모델링 등 DB의 기초나 데이터 이론에 대해서는 별도로 다루지 않는다. 그럼에도 책을 읽고 나면 자신도 모르게 데이터 모델링 개념과 SQL로 제어되는 DB의 원리까지 알게 된다.

필자는 DB 튜닝도 법칙이나 이론이 아닌, 상식선에 가능하다고 소개한다. 어떻게 그게 가능한지를 직접 보여주고 풀어보도록 하는 것이 바로 이 책의 매력이다. 이 책은 오라클 DB를 중심으로 접근하지만, 특정 함수 등을 소개할 때는 SQL Server와 MySQL 등의 DBMS별 차이점도 소개해 준다.

데이터 모델러인 위즈덤마인드의 김기창 대표 컨설턴트는 \"이 책의 진정한 매력은 '인덱스 생성도'에 있다. 한눈에 들어오는 인덱스 생성도를 따라 책을 읽어가다 보면 인덱스를 저절로 이해하게 된다\"고 말했다. 김 대표는 또 \"인덱스 생성도에는 개발자 입장에서 필요한 모델링 기초 지식이 녹아 있으므로, 이론이 필요하지 않는 개발자에게 매우 유용한 책\"이라고 추천했다.

대상 독자
-DB의 특성을 이해하여 시스템 성능을 끌어올리고 싶은 초중급 개발자
- DB의 설계.구현.관리까지 혼자서 책임져야 하는 개발자
- 개발.운영 현장에서 DB 전문가들과 원활하게 협업하기를 바라는 개발자
- DB 또는 데이터 분석 분야로 진출하고 싶은 개발자
- 경험으로 알게 된 DB 지식을 분명하게 정리하고 싶은 DBA
- 실무 지식까지 쌓으면서 SQLP(SQL Professional) 또는 SQLD(SQL Developer) 자격증을 따고 싶은 대학생.취업 준비생`

저자 인터뷰
\"성공과 실패의 경험을 나누자, 용기와 희망을 나누자\"

\"블로그나 책에서 소개하는 방식을 제 방식으로 다시 이해하면서 인덱스를 파고 들었습니다. 그 접근 방식을 소개해 놓은 것이 이 책에서 나오는 '인덱스 생성도'와 '공정쿼리'입니다. … DBA 업무를 하면서 DB의 특성을 파악하고 나니까 이런 게 있었는데 왜 알려주지 않았을까? 하는 생각이 들더라고요. 노하우는 알고 나면 너무나 당연한 건데도 몰랐을 때는 사람을 옭아매는 존재이기도 하죠.\"

□ 이 책을 쓴 배경은.
개발자였을 때 DB 때문에 고생하다가 극복했던 경험과 노하우를 공유하기 위해서입니다.

□ DBA로 일했던 것으로 알고 있습니다.
예. 개발자로 10년 정도 일하다가 우연한 계기로 DBA 일을 하게 됐습니다.

□ 어떤 계기로 DBA가 되었나요.
대형 SI 업체에서 일할 때 우연하게 DB 관리 업무가 주어지더군요. DBA 업무를 했던 선임자가 갑자기 회사를 떠나게 되면서 발생한 일이었습니다.

□ DB에 관심이 많았나 봅니다.
DB 분야는 솔직히 헷갈려할 때 였습니다. 개발 분야는 나름 자신이 있었지만, DB 운영 경험도 없었고 별도로 DB 교육을 받은 적이 없었습니다. 지금 생각해 보면 조금 무모했던 거 같기도 합니다만, 그때 도전했던 것이 매우 잘한 선택이었다고 생각합니다

□ 무리 없이 DB를 운영할 수 있었나요.
처음에는 당혹스러웠지만, 곧 적응할 수 있었습니다. 200대가 넘는 전국 기초 지방자치단체의 DB 서버를 혼자서 관리하는 업무였습니다. 선임자가 수작업으로 관리했던 것을 프로그램을 개발해 자동화하면서 일이 크게 줄어들었습니다.

□ 어떻게 적응했는지 궁금한데요.
평소에 자신감 없던 인덱스부터 제대로 한 번 이해해야겠다는 생각이 들더라고요. 당시만 해도 인덱스 개념이 머릿속에 분명하게 정리되지 않았어요. '인덱스는 무언가를 쉽게 찾기 위한 색인' 정도로 뜻만 보면 이해가 되지만, 그걸 어떻게 쿼리로 구현할지는 늘 헷갈렸을 때죠. 인덱스와 정면 대결할 수밖에 없었습니다. 그랬더니 의외로 제가 DB와 쿼리 작성을 어렵게 생각하고 있었다는 걸 알게 됐습니다. 혼란스러웠던 인덱스를 이해하고 났더니 나머지 것을 대할 때도 자신감이 붙었습니다.

□ 인덱스를 접근했던 방식이 궁금한대요.
계속 고민하고 있었는데, 어느 순간 인덱스는 논리적 '분류'라는 생각이 떠오르더군요. 특별할 것 없는 그 생각이 인덱스를 풀어내는 실마리가 됐어요. 물리적 분류는 동시에 하나만 가능한 분류이지만, 인덱스처럼 논리적 분류는 다양한 분류가 가능한 거죠. 방송국에서 음반을 관리할 때를 한번 떠올려 보세요. PD마다 원하는 곡을 제각각 분류하기를 바랄 겁니다. 그걸 쉽게 가능하게 한 것이 인덱스, 즉 논리적 분류라고 볼 수 있어요.

□ DB는 매우 정교하고 논리적이라서 부담스럽게 여겨집니다.
그럴 수도 있지요. 저도 아직 부족하지만, 개발을 할 때나 DB를 운영할 정도의 (DB) 실력을 목표로 한다면, 상식 선에서 접근할 필요가 있다고 봅니다. 공식이나 이론으로 접근하면 오히려 어려워질 수 있다는 걸 경험했습니다. 개발자들 대상의 사내 DB 교육을 할 때면, 처음에는 긴장하는 모습입니다. 이때 질문 하나를 합니다. 어머니가 시장에서 1kg짜리 밀가루 한 포와 두부 한 모를 사오라고 하면, 어떻게 하겠냐? 하고 질문합니다. 바로 가벼운 두부 한 모를 먼저 사고 무거운 밀가루를 나중에 사서 가져온다고 답합니다. 여기서부터 하나씩 쿼리 작성 노하우를 공유하면, 대부분 공감하더라고요.

□ '상식'이라는 단어에 거부감이 들 사람도 있을 거 같습니다.
도움을 드리기 위해 드리는 경험담이니 이해주지 않을까요(웃음). 알수록 DB는 대부분 물리적 세상에 이뤄지는 일들을 논리적으로 구현한 거구나 하는 생각이 들었습니다. 그 과정은 쉽지 않은 게 사실이지만요. 적어도 받아들이는 입장에서는 경험과 상식을 동원해 받아들일 필요가 있다고 봤습니다.

□ '공감'이라는 표현을 이해로 받아들이면 될까요.
네. 머리로 받아들이면 금방 잊어버리거나 실제 코딩 시 헷갈립니다. 하지만 마음으로 받아 들이면 처음에는 조금 어렵더라도 나중에는 터득하게 된다고 봅니다.

□ 그래서 첫 회에 개발자에게는 다소 낯설 수 있는 PCTREE 파라미터를 소개한 거군요.
예, 질문한 그대로입니다. 이 책의 첫 회에 소개한 PCTFREE/ PCTUSED 파라미터를 봤더니 우리 생활 주변에서 볼 수 있는 물탱크 구조와 너무 닮았다는 생각이 들었습니다. 군대에서 경험했던 물탱크 원리가 바로 떠올랐습니다. 물이 넘치거나 부족하면 센서를 통해 자동으로 보충하기도 하고 잠그는 것처럼 DB도 작동합니다. 하지만 그게 말처럼 간단하지는 않아요. 중간에 센서 오류 등이 발생하죠. DB에도 마찬가지로 단순한 개념이지만, 다양한 변수가 있음을 염두에 두고 개발된 거죠. 이름만 들어도 금방 알 수 있는 유명 DBMS가 바로 다양한 상황을 염두에 둔 제품들이라고 할 수 있어요.

□ 책을 써야겠다고 생각했던 계기가 있었을 거 같습니다.
우연한 계기로 사내 개발자 한 분이 데이터 포털인 DBGuide.net에 연재해 보면 좋겠다고 추천한것이 계기가 됐습니다.

□ 그렇다면 사내에서 유명했다는 말인데요.
개발자로서 제가 고생했던 경험을 꾸밈없이 얘기했더니 공감을 얻었나 봅니다.

□ 어디에서 일했나요.
생명보험사에서 DBA로서 IOA 업무를 주로 했습니다. IOA란 데이터 인풋/아웃풋 관리업무 정도로 이해할 수 있습니다.

□ DBA로 활동하면서 개발자로 일했을 때 경험을 자주 떠올렸을 거 같습니다.
네. 저는 개발자 시절에 인덱스를 어렵게 생각했는데 다른 개발자들도 마찬가지더라고요. 큰 회사의 IT 조직에서 DBA로 일했으므로 수많은 개발자들과 만났죠. 얘기를 하다 보니 (인덱스를) 모르거나 알더라도 자신 없어 하는 개발자들이 의외로 많더라고요. 그래서 사내 개발자들을 대상으로 제 인덱스 접근 방법을 소개하는 자리를 가졌는데 반응이 꽤 좋았어요. 몇 회에 걸쳐 강의를 하면서 간단한 자료집으로 만들었는데 외부로 소문이 났나 봐요. 그게 계기가 돼 글까지 쓰게 됐습니다. 글을 써본 경험이 없어서 처음에는 망설여졌지만, 강의할 때처럼 있는 그대로 담당하게 소개했던 것이 좋게 받아들여졌나 봅니다.

□ 개발자들은 DB 측면에서 어떤 고민을 갖고 있던가요.
우선 제 경우만 보더라도 개발 현장에서 10년 넘게 일했는데도 누가 쿼리 작성 노하우를 가르쳐 주는 경우가 별로 없었습니다. 그래서 습관적으로 쿼리 프로그래밍을 했습니다. 책도 사보고 여러 블로그를 참고하기도 했는데 실무와는 먼 이론 위주였던 게 아쉬웠습니다. 하지만 DBA 업무를 하면서 DB의 특성을 파악하고 나니까 이런 게 있었는데 왜 알려주지 않았을까? 하는 생각이 들더라고요. 노하우는 알고 나면 너무나 당연한 건데도 몰랐을 때는 사람을 위축시키기도 합니다.

□ 책에 매우 다양한 얘깃거리가 들어있다는 게 놀라웠습니다.
데이터 지식포털인 DBguide.net에 40회 정도 연재했는데 그때마다 글 시작 지점이 어려웠어요. 뭔가 공감이 갈 만한 얘깃거리를 제시했어야 했기 때문입니다. 그걸 찾으려고 몇 날 며칠 고민하기도 했습니다. 결국은 제가 지금까지 경험하고 느껴왔던 것을 얘기할 수밖에 없었습니다. 군대 얘기, 고향 얘기, 아이들 얘기가 그 겁니다. 글을 쓰다가 잘 모르는 분야, 예를 들면 마방진 등에 대해 소개할 때는 별도로 공부도 했고요.

□ 이야기를 앞세운 이유라도 있었나요.
처음에는 한두 회 써서 반응이 없으면 글방 '잘리지 않을까' 생각했죠. 어렵게 결정한 일이니 한번 잘해보고 싶다는 욕심이 들더군요. 당연히 나름대로 전략을 세웠죠. 글의 시작 부분에서 독자들의 마음을 열어 놓아야겠다고 생각했죠. 첫 회가 나갔는데 반응이 괜찮았어요. 포털 담당자가 반응이 좋다고 격려해 줘서 계속 힘을 낼 수 있었습니다.

□ 책 제목에서 '노하우'라는 단어가 눈길을 끌더군요.
이 책이 기반이 되는 첫 번째 글을 썼을 때부터 노하우라는 단어를 염두에 뒀습니다. 앞서 간단히 소개했지만, 나중에 알고 나면 아무것도 아닌데 몰랐을 때는 사람을 움츠러들게 하는 것이 노하우이기 때문이죠.

□ 개발자들 가운데는 쿼리는 간단한 일이라고 생각하는 경우도 있었습니다.
SQL은 언어 측면에서 보면 단순한 편이죠. 단순하지만 잘 써야 원하는 DB 성능을 낼 수 있습니다. 원하는 만큼의 성능이 나오지 않거나 문제마저 야기한다면 당장 필요한 것은 무엇일까요? 이런 개발자에게는 DB의 원리와 개념은 아닐 것입니다. DB 성능을 좌우하는 '인덱스'와 분명한 실행계획(plan)을 적용하는 방법을 알아둘 필요가 있습니다. 그래서 이론부터 강조하지 않았습니다. 우리 주변에서 흔히 접할 수 있는 일을 예로 들어서 설명하면서 상식선에서 DB를 잘 활용할 수 있고 나아가 성능까지 끌어올릴 수 있다고 봤습니다. 그래서 내용이 어렵지 않습니다. 하지만 다 읽고 나면, 데이터 모델링 이론에서 강조하는 엔터티 설계 개념까지 자신도 모르게 습득하게 될 겁니다.

\"쉽게 설명하지 못하는 이유는
그것에 대해 제대로 알고 있지 못하기 때문이다.\" _아인슈타인

□ DB 성능을 끌어올리는 튜닝 책이라고 볼 수 있네요.
그럴 수도 있고 그렇지 않을 수도 있습니다. 튜닝이라는 말이 너무나 폭넓게 사용되는 거 같아서요. 튜닝은 개발 프로세스 단계로 보면 사후 접근 개념이라고 할 수 있는데요. 개발 생산성과 관리성을 높이려면 사전 튜닝, 즉 개발자 측면에서부터 튜닝을 해야 한다고 보기 때문에 튜닝이라는 말을 앞세우지 않았습니다. 물론 DBA나 DB 튜너 입장에서 보면 튜닝 책이라고 볼 수 있습니다. 분명한 것은 개발자를 포함해 DB 전문가들이 튜닝을 잘하게 하는 책입니다. 이 책은 튜닝이라는 말 대신에, 인덱스를 제대로 이해하여 '공정쿼리' 즉 쿼리를 제대로 짜면 저절로 성능과 관리성을 끌어올리는 노하우를 소개합니다. DB 튜닝이라는 말을 하지 않고도 튜닝을 한 셈이죠.

개발자 입장에서 간절함이 묻어나더라고요.
누구나 유독 받아들이기 힘들었던 것들이 한두 개씩은 있었을 것입니다. 알고 나면 아무것도 아니었는데도요 하지만 골칫거리 같던 존재가 우연한 계기로 너무나 쉽게 풀렸던 경험 또한 갖고 있을 것입니다. 자신에게 딱 맞는 책을 만났거나 귀에 쏙쏙 들어오게 설명해주는 동료나 선생님이 그 역할을 했을 수도 있습니다. 이 책이 SQL DB를 제대로 배우고 싶은 개발자와 여러분에게 또 한번의 그런 해결의 경험을 드릴 수 있기를 바랍니다. (끝)

김기창  : 이 책의 장점은 쉽게 쓰였다는 점입니다. DB에 익숙하지 않은 개발자에게 '강추하는' 이유입니다. 이 책의 진정한 장점은 '인덱스 생성도'입니다. 인덱스 생성도를 따라 책을 읽어가다 보면 인덱스
를 이해할 수 있게 됩니다. 인덱스는 쿼리를 다루는 개발자가 꼭 알아야 하는 부분입니다. 모델러 입장에서 이 책은 모델링에 대한 기초 지식을 기반으로 쓰여졌다는 점을 높게 평가하고 싶습니다. SQL로 결과만 보여주면 된다는 견지가 아니라 엔터티 설계가 중요하다는 점을 여기저기서 강조하고 있습니다. 이 책이 많은 개발자에게 자신의 가치를 한 단계 높일 수 있는 계기가 될 수 있
기를 바랍니다.

기민용 (gurubee.net 운영진)  : 비유 방식으로 어려운 개념을 쉽게 이해하도록 도와줘
쉽고 새롭게 알려주는 책. 경험이 많지 않은 개발자들이 늘 혼란스러워하는 인덱스 개념을 '인덱스 생성도'라는 그림으로 쉽게 소개한 점이 눈길을 끈다. 생활 속 경험을 토대로한 비유 방식의 접근법은 너무나도 쉽게 공감이 되어 어려운 개념을 쉽게 이해하도록 도와준다. 알고 있던 내용도 명확하게 정리해주는 느낌을 준다. 이러한 생활밀착형 비유법은 이 책만이 가진 독특한 장점이다. 개발자는 물론 DB 전문가에게도 충분히 도움이 될 만한 책이다.
 

서문 '쉬운 것이 바른 것'
이 책의 특징과 구성

1회: PCTFREE, PCTUSED
물탱크 구조와 오라클의 블록 옵션 비교하기
- 약방의 감초: PCTFREE와 PCTUSED 블록 옵션
- PCTFREE 10%와 PCTUSED 40% 설정값 바꿔본 사람 있나요?
- 둘의 합이 100에 가까워서는 안 된다
- 맥가이버 병사의 순발력이 문제를 해결하다
- 고정관념에서 벗어나기를 바라며
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 1

2회: 인덱스
이산가족 찾기로 배우는 DB의 분류 원리
- KBS 이산가족 찾기 생방송
- 대형 할인매장의 전략
- '도둑은 분류를 좋아한다'
- 개미 세계의 분류
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 2

3회: 인덱스
인덱스는 분류, 물리적 분류와 논리적 분류
- 물리적 분류에서 논리적 분류로
- 거실의 책장 분류
- 라디오 방송국의 음반 분류
- 분류 대상과 분류 정보의 분리
- 물리적 분류와 논리적 분류
- 인덱스는 논리적 분류
- 지식은 그것을 필요로 하는 사람의 몫
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 3

4회: 인덱스
인덱스에 대한 오해와 진실
결혼인가, 화혼인가!
결합인덱스의 컬럼 순서 결정방법
추천하는 결합인덱스의 컬럼 순서
원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 4

5회: 인덱스
쉬운 것이 바른 것! 인덱스 컬럼 선정 기준
- 바른 것이 쉽다
- 성능 제고를 위해 우선 고려할 것, 인덱스
- 인덱스 대상 후보컬럼 선정 기준
- 분포도가 좋은 컬럼인가?
- 인덱스보다 풀스캔이 유리할 때
- 논리적 분포도로 판단할 때의 위험
- 특별한 물고기
- ORDER BY 절 컬럼도 인덱스 후보일 수 있다
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 5

6회: 인덱스
분류 본능을 활용하라 '인덱스 끝장리뷰'
- 인덱스 수는 적정해야 한다
- 인덱스는 위치정보와 순서정보로 구성됐다
- 조건절에 사용하는 인덱스와 조인절에 사용하는 인덱스
- 인덱스 생성/삭제 시 고려사항
- 결합인덱스의 컬럼 순서 결정방법
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 6

7회: 인덱스
누구도 알려주지 않았던 '오라클 인덱스 생성도'의 비밀o72
- 어머니의 심부름: 두부가게와 쌀가게
- 오라클의 RBO 방식과 CBO 방식
- 인덱스 생성도의 기본 규칙
- 인덱스 생성도에 대한 이해
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 7

8회: 쿼리
누구도 알려주지 않았던 SQL 작성의 규칙과 방법o89
- 공정무역과 공정여행, 공정쿼리
- 공정쿼리
- 나막사 주부의 심부름 메모지
- 나계획 주부의 심부름 메모지
- 공정쿼리, 반드시 이렇게 작성하라!
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 8

9화: 쿼리
퀴리 최적화와 튜닝을 한 번에! 공정쿼리 작성법o103
- 배낭여행 스마트앱 만들기
- 오라클 CBO 방식과 통계정보
- 테이블 접근 순서 규칙 1: 진입형 테이블을 결정하라(사원테이블 선택 접근 시)
- 테이블 접근 순서 규칙 2: OUTER JOIN보다 INNER JOIN을 우선하라
- 테이블 접근 순서 규칙 3: 연결 확장형보다는 연결 축소형 테이블을 우선하라
- 인덱스 생성도와 공정쿼리 재작성하기
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 9

10화: 쿼리
만능 쿼리와 한방 쿼리, DB는 집합적 사고로 접근해야
- 나쁜 사람이 세상을 발전시킨다?
- 심각한 만능 쿼리
- 핵심 조건절의 수만큼 쿼리를 분리해야
- 한방 쿼리에 대한 이해
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 10

11회: 튜닝, 옵티마이저
오라클 옵티마이저, CBO와 RBO 이해하기
- 어머니의 심부름: 두부가게와 쌀가게
- CBO 방식과 RBO 방식
- CBO 방식: 옵티마이저와 통계정보, 실행계획
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 11

12회: 쿼리, 쉬어가는 이야기
재미있는 DB 이야기 '60 갑자와 쿼리'
- 10천간과 12지지o127 | 60갑자에서 규칙 찾기
- 10천간과 12지지 그리고 오라클 쿼리
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 12

13회: 조인
그림으로 풀어보는 오라클의 조인 방식
- 택시 같은 Nested Loop Join
- 짝꿍 정해주기와 같은 Sort Merge Join
- 성씨 구역처럼 구분하는 Hash Join
- 오라클 조인 방식의 특징 비교
- 조인 방식과 조인 순서 결정하기
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 13

14회: 실행계획
쿼리를 작성한 후에는 실행계획을 확인하라o143
- 실행계획을 알고 있어야 하는 이유
- 실행계획을 늘 확인하자
- 오라클 옵티마이저의 실행계획과 개발자의 실행계획
- 바인드 변수와 하드 파싱
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 14

15회: 튜닝, 힌트절
놓치면 후회할 오라클 힌트절 7가지
- 힌트절로 옵티마이저의 실수 차단
- 접근 방법을 결정하는 힌트절: USE_NL과 USE_HASH
- 자원 사용을 결정하는 힌트절: INDEX, FULL, PARALLEL
- 배치 튜닝의 마법사 같은 힌트절 삼총사: USE_HASH, FULL, PARALLEL
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 15

16회: NULL
개발자들의 영원한 숙제 NULL 이야기o173
- 이길 수 있을 때 공격하라
- 쉬우면서 어려운 존재, NUL
- 개발자를 힘들게 하는 NULL
- NULL 회피 전략
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 16

17회: 튜닝, 힌트절
개발자를 위한 유용한 선물, GATHER_PLAN_STATISTICS 힌트절
- 호미, 무시할 수 없는 그 존재감
- GATHER_PLAN_STATISTICS, 무시할 수 없는 엄청난 존재감
- 튜닝을 위한 최고의 힌트절
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 17

18회: 튜닝
놓치기 아까운 오라클의 유용한 기능들
- COMMIT 이전의 상태로 되돌리는 기능 FLASHBACK
- 오라클에서 스케줄 작업 사용법
- SAMPLE 혹은 SAMPLE BLOCK을 이용한 SAMPLE SCAN
- 종을 횡으로 구현하는 함수 WM_CONCAT
- 횡을 종으로 구현하는 함수 REGEXP_SUBSTR
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 18

19회: DICTIONARY
오라클 딕셔너리 기반의 DB 툴 프로그램 'FreeSQL'
- 씨줄과 날줄o208 | 오라클 딕셔너리o209 오라클 딕셔너리를 이용한 DB 툴 개발
- 새로운 DB 프로그램 개발의 주인공은 바로 나
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 19

20회: DICTIONARY, 쉬어가는 이야기
이제는 말할 수 있다, 주식 자동매매 프로그램(상)
- 프로그래머의 길에서 벗어나다
- IMF! 구조조정! 주식! 새로운 길을 찾다
- 주식 자동매매 프로그램을 개발하다

21회: DICTIONARY, 쉬어가는 이야기
이제는 말할 수 있다, 주식 자동매매 프로그램(하)
- 공시·뉴스 수집 프로그램
- 공시·뉴스 분석 프로그램
- 주식 자동매매 프로그램
- 테이블 구성에 대한 이해
- API를 알면 보이는 것들

22회: 에러 메시지
개발자들이 자주 접하는 오라클 에러 메시지
- 김기사와 빅데이터
- '조선시대에도 빅데이터가 있었다'
- 오라클 에러 메시지 톱10
- 오라클 에러 메시지를 마무리하
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 22

23회: 함수, 쉬어가는 이야기
사라진 날짜를 찾아라, 오라클에서 달력 다루기
- 곶감 만들기에 도전하다
- 동양과 서양의 달력
- 사라진 날짜를 찾아라
- 그레고리력과 오라클 DB
- 그레고리력 규칙을 이용해 요일 구하기
- 달력 팝업 창 쿼리 만들기
- 스토리를 마무리하며
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 23

24회: 랜덤 함수
오라클 랜덤 함수와 사용자 정의 함수
- 오라클 랜덤 패키지 DBMS_RANDOM
- 문자열을 역순으로 리턴하는 REVERSE 함수
- 사용자 정의 함수를 만들어 쓰기
- 사용자 정의 함수 ISNUMERIC
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 24

25회: 공정쿼리
그림으로 배우는 '공정쿼리와 인덱스 생성도'
- 오라클 CBO 방식과 통계정보
- 장바구니 \u003d 무엇을 + 어떻게
- 공정쿼리 \u003d 무엇을 + 어떻게
- 인덱스 생성도에 대한 이해
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 25

26회: 오라클 파라미터
디폴트 세팅의 함정과 오라클 파라미터
- 디폴트 세팅의 영향
- 디폴트 세팅의 함정
- '사용자 설정은 의지의 설정'
- 오라클 파라미터의 이해
- 오라클의 주요 파라미터
- 무모한 도전과 경험 사이에서
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 26

27회: 쿼리, 쉬어가는 이야기
재미있는 DB 이야기, SQL로 구현하는 마방진
- 마방진은 현재 진행형
- 3차 마방진
- 4차 마방진
- 4차 슈퍼 마방진
- 3차 입체 마방진
- 기타 각종 마방진
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 27

28회: 블록
오라클 운반 최소 단위, 블록
- 오라클 블록에 대한 이해
- 오라클 블록의 크기와 OLTP & OLAP
- 오라클 블록과 Row Chaining & Row Migration
- 오라클 블록과 성능의 연관성
- 원리를 이해하고 논리로 풀어가는 쉬어가는 스토리 DB 문제 28

29회: 인공지능, 쉬어가는 이야기
데이터가 촉발한 인공지능과 그 새로운 도전
- 컴퓨터와 인간의 대결?
- 구글의 인공지능 알파고
- 인공지능·머신러닝·딥러닝
- 머신러닝
- 딥러닝

30회: 쉬어가는 이야기
DB 엔지니어의 계산 방식과 기계의 계산 방식
- '옥뮤다' 택배 실종사건o320 두 번째 버스를 타자
- 인간의 계산 방식 vs. 기계의 계산 방식

31회: 튜닝, 페이징
페이징 처리에 대한 이해
- 프로그램 페이징 처리와 서버 페이징 처리
- 전체 범위 페이징 처리와 부분 범위 페이징 처리
- MySQL의 LIMIT와 오라클의 ROW_NUMBER
- 최고의 페이징 처리와 최적의 페이징 처리

32회: 튜닝, 쿼리
보기 좋은 떡이 먹기도 좋다, 좋은 쿼리 좋은 성능
- 무질서와 질서
- 옵티마이저가 동일한 쿼리로 인식하도록 작성
- 표현 방식이 다르면 다른 SQL 문으로 인식

33회: 튜닝, 테이블 분할
성능 개선을 위한 테이블 수직분할과 수평분할
- 테이블 분할을 알아야 하는 이유
- I/O 성능 개선을 위한 수직분할
- 처리 성능 개선을 위한 수평분할
- 수직분할과 수평분할의 결정 기준

34회: 튜닝, 채번
성능 제고를 위한 채번 이해와 방식별 장단점 비교
- 채번에 대한 이해
- 채번 테이블을 이용하는 방식
- 테이블에서 최댓값을 이용하는 방식
- 시퀀스를 이용하는 방식
- 채번 방식에 대한 장단점 비교

35회: 튜닝
개발자를 위한 튜닝실전 1편: 생명체처럼 다뤄라
- 인덱스, 필요한 데이터를 빨리 찾기
- GROUOP BY 절 사용과 성능 이슈

36회: 튜닝
개발자를 위한 튜닝실전 2편: 줄이고 또 줄여라
- 줄이고 줄이고 또 줄이자
- 홍길동을 찾아라

37회: 튜닝
개발자를 위한 튜닝실전 3편: 인덱스를 사용하지 않을 때 대처법o361
- 인덱스를 사용하지 않는 경우 1: 컬럼 변형 시
- 인덱스를 사용하지 않는 경우 2: 타입 변형 시
- 인덱스를 사용하지 않는 경우 3: NULL 사용 시
- 인덱스를 사용하지 않는 경우 4: 부정형 사용 시
- 인덱스를 사용하지 않는 경우 5: LIKE 사용 시
- 인덱스를 사용하지 않는 경우 6: 인덱스 경합 발생 시
- 인덱스를 회피하는 방법

스토리 DB 문제 풀이와 정답
찾아보기