필자가 여러 회사를 다니며 살펴 본 바로는 대부분이 기본 키를 클러스터 색인으로 설정해 놓고 있었다. 또한 강의 중에 확인해 보아도, 대부분이 당연히 클러스터 색인이 기본 키이어야 한다고 생각하고 있었다. 과연 그럴까?

그렇지 않다. 클러스터 색인은 테이블마다 하나 밖에 존재할 수 없으며, 속도(Performance)에도 많은 영향을 미치는 요소이므로 기본 키를 무조건 클러스터 색인으로 설정하는 것은 옳지 않다. 일반적으로는 정렬되어 있어야 더 좋은 속도를 낼 수 있는 컬럼을 클러스터 색인으로 만드는 것이 가장 좋다.

예를 들어 사원 번호가 기본 키이며 CL인 경우를 흔히 보게 되는데, 업무 상 사원 번호를 "10번부터 100번까지"라는 식으로 범위를 주어 찾을 때가 얼마나 많을까? 그 보다는 오히려 이름순으로 성이 "김"씨인 사람을 찾을 때나, 부서가 "영업"인 사람을 찾을 때가 더 많을 것이다. 그렇다면 오히려 이름이나 부서에 대해 클러스터 색인을 설정하는 것이 옳다.

앞서 말한 대로 이것은 전적으로 업무의 성격에 따라 얼마든지 달라질 수 있다. 여러분 회사의 클러스터 색인을 다시 한번 점검해 보자.

결론적으로, 클러스터 색인은 한 테이블에 하나만 존재할 수 있으며, 범위를 주고 값을 찾을 때에 매우 도움이 된다. 흔히, Primary Key는 무조건 클러스터 색인을 만드는데 이것은 옳지 않다. 반드시 색인을 만들기 전과 후의 속도를 비교해 보고 결정해야 한다. 그리고 7.0부터는 앞서 언급한 바와 같이 넌 클러스터 색인이 클러스터 색인의 키 값을 포인터로 갖고 있기 때문에 클러스터 색인의 키 값이 20바이트 이상 된다면 성능은 형편 없을 것이 불 보듯 뻔하다. 아무리 범위를 주고 찾는 것이라고 하더라도 키 값이 크다면 클러스터 색인을 사용하지 말아야 한다.

전형적으로 전산에서는 데이터를 처리할 때 입력과 출력에 초점을 둔다. 예를 들면, 무엇이 입력되면 무엇이 출력되는가에 대해서 관심을 갖는 것이다. 그 결과를 나타내기 위해서 필요한 과정을 구현하는 것이 바로 전산에서 할 일이라고 생각해 왔다. 그런데, 이런 식으로 처리하는데 약간의 문제가 생기기 시작했다. 업무의 흐름이 정적으로, 또는 자주 바뀌지 않을 때는 문제가 없었다. 애초에 전산화라는 것은 늘 '일상적으로' '반복되는'일에 대해서 자동화 시키는 것이었다. 그러나 산업 사회가 발전하면서 점점 변화의 속도가 빨라졌다.

예를 들면 그전에는 어떤 한 프로젝트를 진행해서 프로그램을 완성하면 처음에만 몇번 손을 봐주면 거의 2,3년간 다시 고칠 필요가 없었다. 그러나, 이제는 그런 경우는 작은 규모나 몇 몇 특이한 경우를 제외하고는 보편적인 일이 아니다. 새로운 프로그램을 짜 놓고 정상화 시켜서 더 이상 손 볼 필요가 없는 수준이 되었다 싶으면 부서 조직 개편이 일어나서 다시 손을 봐야 하고, 기획부서나 영업부서 등에서는 새로운 보고자료를 요구해 온다. 늘 새롭게 변하는 양식에 대해 처리하고자 하다 보니 전산 업무라는 것은 마치 치다꺼리하는 업무처럼 되어 버렸다.

이런 과정으로 몇 개월, 몇 년이 쌓이게 되면 전산부서는 욕을 먹게 되거나, 더 이상은 이런 식으로 일을 처리할 수 없다고 버티게 된다. 회사는 회사 나름대로 비용투자는 엄청나게 했는데 쓸만한 결과는 나오지 않는다고 투덜댄다. 이뿐인가? 전산부서의 직원들은 전산을 3D업종이라고 생각하게 되고, 어느 정도 경력이 쌓이면 그 실력을 더 발전시키지 못하고 관리직으로 이동하게 된다. 그래서 머리 허연 프로그래머를 찾기는 무척 힘든 것이 사실이다. 이런 문제를 해결할 방법은 없을까?

1984년 즈음에 E. F. Codd 박사는 그의 논문에서 왜 현업 부서들의 요구를 전산실에서는 제대로 수용을 못할까라는 고민을 하였다. 그리고는 그는 그 결론을 사용하고 있는 데이터베이스 시스템이라고 내렸다. 지금까지 사용해 오던 데이터베이스는 계속적으로 변화하는 환경에 빠르게 대처하지 못한다는 것이다. 그래서 그는 현업부서의 요구를 분석하고 이를 신속하게 처리할 수 있는 새로운 데이터베이스 시스템을 탄생시켰다. 그것이 바로 R-DBMS인 것이다.

많은 프로그래머들이 기교에 충실한다고 생각한다. 새로운 tip이나 기술, 기교에는 민감해서 그런것을 자신의 프로그램 속에 구현을 해두면 가슴이 뿌듯해지는 것은 사실이지만, 그렇다고 해서 기본을 무시하는 것은 정말 문제가 있지 않을까 ?

관계형 데이터베이스는 그 말에서 풍기는 것처럼 '관계'가 매우 중요한 데이터베이스 시스템이다.

한 테이블이 그 자체로 존재하는 경우도 있지만, 실제 환경에서는 다른 테이블과 연관된 관계'를 맺고 있는 것이 더 흔하다. 예를 들면 사원 테이블은 부서코드 라는 것으로 부서 테이블과 관계를 맺고 있다. 부서 테이블에는 1003이라는 부서가 없는데 어떤 사원이 부서코드에 1003이라는 값을 가지고 입력된다면, 이것은 비정상적인 데이터이며, 입력을 거부해야 하는 상황이라고 할 수 있다.

앞서 다룬 것처럼, 전통적으로 이런 입력 거부에 대해서는 프로그램에서 처리해 왔다. 그러나 관계형 데이터베이스에서는 이것을 데이터베이스 서버가 처리한다.

위의 예에서 만약 부서 테이블에 부서 코드라는 컬럼의 크기를 처음에는 문자열 4바이트를 잡아두었다가 자리가 모자라 5자리로 늘린다면 사원 테이블을 비롯한 모든 부서코드를 참조하는 테이블들 역시 변경되어야 한다. 일반적으로 프로젝트의 초기 단계에서는 이런 일이 약간은 용납 되지만, 어느 정도진행된 후에는 쉽게 허용될 수 없게 된다. 그래서 R-DB는 전통적인 데이터베이스 개발 기법과는 달리 데이터 모델링이라는 과정이 꼭 필요하고, 설계에 들어가는 시간이 오히려 개발에 들어가는 시간보다 월등히 많이 필요하다. 데이터 모델링에 대해서 이 장에서 비록 간단히 다루기는 하지만, 너무나 광범위한 주제이므로 독자들은 이것이 전부라는 오해를 하지 말아야 한다. 이에 대해서는 별도의 책들을 통해서 꼭 공부를 따로 하기를 바란다. 추천도서의 목록들을 참조하도록 하자.


데이터 모델링이라는 것은 이렇듯 "관계"를 중요시 여기는 관계형 데이터베이스에서 매우 중요한 기초 개념이 된다. 제대로 모델링 과정을 거치지 않은 데이터베이스의 설계는 추후에 매우 많은 문제들을 일으키게 된다. 대부분의 데이터베이스 전문가들은 성능 향상에 있어 중요한 요소로 데이터베이스 디자인을 들고 있다. 처음에 설계를 잘못하면 아무리 튜닝을 해도 한계에 부딪히게 된다.

과거의 전통적인 데이터베이스 개발에서는 전체 중 약 30% 정도의 시간을 데이터베이스 디자인에 할당했다면 관계형 데이터베이스에서는 전체의 개발 시간중 심하면 약 70%~80%의 시간을 데이터베이스 디자인에 할당할 정도로 그 중요성이 커졌다.

따라하기를 하다보면 복잡한 설명 필요없이 이해 될 정도로 쉽게 SQL 서버 2000을 익힐 수 있다. 여러 강의와 세미나에서 폭발적인 인기의 주인공, 정원혁 강사가 직접 쓴 SQL 서버 2000 개발자를 위한 지침서 초보자를 위한 자세한 쿼리 분석기의 사용법 설명과 데이터베이스 설계의 경험이 없는 사람들을 위한 강화된 데이터베이스 모델링을 설명했습니다. SQL 서버 2000만의 사용자 정의 함수, INSTEAD OF TRIGGER, 인덱스된 뷰, 새로운 자료형, 전체 텍스트 등에 대한 새롭고 강화된 내용을 이해하기 쉽도록 설명했습니다. 커서, 동적인 문장 실행(EXECUTE, sp_execute), 하위 질의 등에 대한 강화된 내용을 따라하기식 구성에 떄라 설명했으며 고급자도 만족할 만한 더욱 강화된 색인, 트랜잭션에 대한 내용을 다루었습니다.