[SQL고수되기] 두번째 이야기

출처 : 네이버지식인 노하우 (http://kin.naver.com/knowhow/detail.nhn?d1id=8&dirId=8&docId=552804&qb=U1FMIOqzoOyImOuQmOq4sA==&enc=utf8&section=kin&rank=2&search_sort=0&spq=0)

첫번째 이야기에서 물리/논리 엔티티라는 말이 나왔었습니다.
이것에 대해 구체적으로 이야기를 해볼까합니다.

물론 쿼리를  잘 짜는 것도 중요합니다. 그러나 가장 중요한 것은 물리적인 Entity입니다.
최초에 DB설계시에 논리적으로 RDBMS에 맞게 분석을 통해 잘 정리된(정형화된, 구조화된, 무결성의...) 데이터일수록 쿼리 설계 시 막강한 영향력을 발휘하게 됩니다.

쿼리를 짜려다 보니 헉, 이건 생각 못했네, 테이블 바꿔야겠어... 음 어떻게...
보통 이런 생각이나 말들 무지 많이 하게 됩니다.
그때, 그 당시의 요청(요구)사항에 1:1로 Mapping되게 설계되었다면 그당시는 검토/승인되겠지만 시간이 지나고 데이터가 쌓이고... 돌아올 수 없는 강을 건넜을 때 위와 같은 일이 생긴다면 어떻게 할까요? 보통 예산을 잡고 Version Up이라는 명명하에 2차 설계에 들어가겠지요. 당연히 핑계 아닌 핑계를 되면서.. 많이들 경험했을 것으로 생각됩니다.

앞에 경우는 그나마 당행입니다. 바꿀순 있기에. 하지만 더 난감한 경우는
아~~~주 오랜된 시스템의 경우입니다. 기본 10년이상 지났고 쌓인 데이터의 량이 테라바이트
(제 경우라면 현제 시스템이 8000기가바이트 Tablespace(TS)가 48개이고, 70%정도의 TS가

Used 85%입니다.)라면 얘기가 달라집니다. 그당시 순차적(Sequence Table) 방식이였다면

더더더더더욱 난감한 상황에 봉착하게 됩니다.

 

이처럼 잠깐의(잠깐이란 그리 짧진 않음 ^^) 실수로(물론 착오일수 있음) 넘겨버린 일이 다음엔
엄청난 결과로 돌아온다는 것을 DB 분석,설계하시는 분들은 명심 또 명심해야 할것입니다.

 

그럼 어떻게 하면 물리적 Entity(테이블) 설계에 도사가 될 수 있을까요.
이건 제 선입견 일 수 있지만 메모하는 습관을 가져야 한다고 생각합니다. 메모하는 습관?
너무 쉽지 않은가? 너무 단순하지 않은가? 라고 말씀하시는 분들도 계실것입니다. 혼자의 힘으로
독불장군이 되기 보다는 여러 사람들 설계담당자,사용자,일반고객,업무전문가 발생될 수 있는
또는 발생가능 일이나 사건, 내용에 대해 일일이 기록하고 이 내용을 기준으로 Entity를 순차적으로
정규화 시킨다면 그만큼의 리스크는 줄일 수 있을것입니다. 자기 자신의 짧은 경험이나 소견으로
Defined시킨다면 책임은 그담음 사람의 목으로 돌리게 되는 것입니다. 따라서 반드시 아는 길도
물어가라 라는 말처럼 기록하고 정리하고 문서화하고 달팽이 돌듯이 반복해야만 질 좋은 정보들이
생겨나게 될것입니다.

 

잠깐 쉬어가는 시간으로 실제로 2002년도경 제 경험을 얘기해볼까합니다. 공공기관 국방-조달 연계
시스템을 개발하기 위해 투입된 적이 있었습니다. 구축(SI)기간은 대략 4개월이고 순수하게 유저
보단 시스템간의 정보 연계가 목적이였기에 웹보다는 시스템 적인 작업이 많았습니다. 1차,2차,3차
....n차 테이블 설계하는데만 2달 반이 걸렸습니다. 실제 구현은 보름. 테스트(단위,사용자,통합)는
거의 한달정도 진행되었습니다. 물론 잘하시는 분들은 금방이였겠지만 기관 담당자들간의 이슈나
실제 시스템 간의 Risk, 또 연계 시스템간의 차이 등등 서로 다른 이견과 내용, 상황등이 있어
출장,회의,정리 이렇게만  2달이 넘게 소요되게 되었습니다. 하지만 다들 서두르지 않았던 것으로
기억합니다. 다행이 다들 DB설계의 중요성을 알았기에 가능했던 일이였던 것으로 기억됩니다.

후후 쉬어가는 시간이라고 말해놓고 너무 딱딱한 얘기였네요.

앞으로 몇번(대략 20~30 예상)이 될지 모르지만 이야기를 만들것입니다. 그때가 되면 이런 글(말)보단
실제 쿼리 테크닉이 이야기 될텐데 아마도 머리가 아프실 분들도 계실지 모르겠습니다. 단순 쿼리가
아니라 튜닝이 병행되는 쿼리라면 더더욱 난감하실수도 있으실겁니다.
하지만 기본이 갖춰진다면 아하~ 라는 감탄사가 나오실꺼라 믿어 의심하지 않습니다.
다시한번 말씀드리면 분명 구축된 물리적인 Entity와 설계하려는 논리적인 Enitty(SQL Query)는
다르다는 것을 말씀드고 싶습니다.

 

다음 이야기에서는 물리적인 Entity(테이블) 생성 잘하기에 대해 이야기해볼까 합니다.

 

내가 잘 만든 테이블 열 쿼리 안부럽다. 아자!! 화이팅