[지디넷코리아]SQL 서버 개발자들은 재사용성에 대한 객체 지향 프로그램 방식을 주목해야 한다. 또한 데이터베이스를 재사용함으로서 불필요한 일을 어떻게 줄일 수 있고, 어떻게 하면 개발 시간도 획기적으로 단축시킬 수 있을지 면밀히 살펴볼 필요가 있다.

일에 따라 SQL 서버만 갖고 작업할 수도 있고, 닷넷, 자바, 델파이 같은 언어로 작성된 다양한 프론트엔드 애플리케이션을 이용해 SQL을 사용할 수도 있다. 그런 언어에서는 재사용성에 대한 개념에 익숙할 것이다. 하지만 SQL 개발자들은 데이터베이스 재사용을 거의 생각하지 않는다.

한번 생각해보자. 여러분은 고객 관리에서부터 판매 주문, 구매 주문 등등에 걸쳐 동일한 것들을 만들어낸다. 이런 일은 아주 원초적 수준이지만 이를테면 보통 회계 시스템용으로 작성하는 미수금 계정, 채무 계정, 재고 관리 등과 같은 모듈에서는 좀 더 고차원 수준에서 추상화할 수 있다.

각 모듈마다 필요로 하는 테이블은 고객별로 혹은 데이터베이스별로 서로 많이 다르지 않다. 그런데 왜 분리된 데이터베이스로 설계하지 않고 있는가?

사실 그에 대한 답은 ‘납기에 대한 압박’ 때문이다.

개발자들은 데이터베이스에 공통 객체를 추상화할 여유가 없다. 이런 점에서 우리는 객체 지향하는 사람들에게 뭔가 배워야 한다. 그들은 재사용성이 아키텍처 측면에서 효과적이고 경제적인 면에서 건전하다는 이야기를 따르고 있다. 그런데 데이터베이스 개발과 관리를 하는 우리 대부분은 같은 방식을 따르지 않고 있다.

객체 지향적으로 데이터베이스 개발에 관해 생각을 시작할 때이다. 기본 수준에서 본다면 고객, 업체, 직원에겐 공통적인 것이 많다. 한 단계 높여서 여러분이 주소(도시, 지역, 국가)를 모델링하는 방식은 각기 데이터베이스마다 아주 동일하다. 한 단계 더 높이면 판매 주문 항목은 여러분이 뭘 팔든 간에 반드시 동일하다.

객체 지향하는 사람들이 사용자 애플리케이션의 고유 특성을 극복하는 것과 같은 방법으로, 우리도 데이터베이스 설계의 고유 특성을 극복할 수 있다.

이 과정에서 가장 중요한 건 단순히 우리가 할 수 있을지 결정하는 것이다. 필자의 경우 동일한 원칙이 데이터베이스 설계와 객체지향 설계에 적용된다는 걸 깨닫게 됐고, 이를 바탕으로 기존 프로젝트를 데이터 모델링 도구로 옮겨서 유용한 범위 내에서 추상화하는 데에 2주 정도의 시간 밖에 걸리지 않았다.

동일한 도구를 사용해서 단순 객체(고객 테이블)와 복잡한 객체(미수금 계정)를 본인이 직접 생성한 새로운 데이터베이스로 신속하게 가져올 수 있게 됐다. 개발 시간에서 얻는 이득도 상당하다.

데이터베이스 재사용에 관한 2가지 방법
이렇게 바꾸는 데에는 두 가지 접근법이 있다. 각각의 방법에 대해 장단점을 모두 제시할 것이지만 어떤 접근법이 여러분 상황에 적합한지 결정하는 건 여러분들의 몫으로 남겨둘 것이다.

첫 번째 접근은 관심있는 특정 ‘미수금 계정 같은 객체’에 대한 관심 테이블을 담고 있는 수많은 데이터베이스를 서로 연결하는 것이다. 이 말은 클라이언트 프로그램 입장에서 단지 하나의 데이터베이스가 있는 것처럼 보이도록 현업에서 사용중인 데이터베이스에 뷰, 저장 프로시저, UDF를 포함하라는 뜻이다.

이렇게 하면 미수금 계정 "객체" 안에서 하나의 객체가 변경된다면 가상 데이터베이스는 그 변화 내용을 "상속"할 것이다. 단점은 외래 키(foreign key)는 실제 하나의 데이터베이스 내에서만 동작한다는 것이다. 따라서 트리거를 사용해야 하고 느려질 수밖에 없다.

두 번째 접근은 "객체" 데이터베이스를 현재 프로젝트로 가져오는 것이다. 긍정적인 측면은 트리거 대신 외래 키를 사용할 수 있다는 것이다. 단점은 미수금 모델처럼 객체 중 하나가 변하면 해당 변화 내용이 다른 데이터베이스에 적용되도록 수작업을 해야 한다는 것이다.

객체로서 데이터베이스를 생각하면 많은 이점을 얻을 수 있다는 점을 여러 번 강조하고 싶다. 객체지향을 구현하기 위해 관계형 데이터베이스가 아닌 객체지향 데이터베이스가 꼭 필요한 것은 아니다. 관점을 바꾸는 것만으로도 충분하다. @