안녕하십니까...

전 그냥 학교 다니면서 ERP 개발을 하는 업체에 있는 일반 학생입니다..

다름이 아니라 ERP, CRM, DSS같은 솔루션에서는 Database가 없어서는 안되는 필수 요소가 되어버린 시점입니다..

여기서 우리회사에서 그렇게 보는지는 모르겠지만...

데이터베이스 만능주의가 아닌가 하는 생각이 들어서 입니다..

현재 사용하는 DBMS는 MSSQL이며, 비교적 고급(아니 완전 고급) DBMS에 속한다고 생각합니다.

그도 그럴것이 DB자체가 OS와 개별적으로 CPU의 캐쉬라던지 메모리영역, CPU의 어느 한정영역을 독점하고 들어가는 기본적인 특성부터 시작하여,

에디션별 클러스터링, 그리고 고급 DBMS의 여러기능(Trigger, Stored Procedure, Functions, .. ETC)등을 이용하여 좀더 빠르고 안정적인 환경을 만들려고 한다는데 기인한다고 보고 있습니다..

여기서 모든 분들께 여쭤 보고 싶은 것이 있습니다..

Transaction ,즉 비지니스 로직을 풀어감에 있어 하나의 모듈이 확실히 안정적으로 이루어지는 그 종결점의 존재에 의해 DBMS가 만능인가 하는것입니다..

물론 트랜잭션은 COM, COM+에서는 지원하는 기능이긴 합니다만,

COM, COM+의 트랜잭션은 Serialized된 것...즉 Tasking을 생각한다면 상당히 고려해야 할 점이 많다라고 생각하여 일반 프로그램에서 지원할수 있는 트랜잭션을 DB의 Transaction자체의 편리함과 안전함으로 인해 DB서버에 부하를 감수 해 가면서 DB에 로직을 넣어버리는 거 같아서 말입니다..

MSSQL의 경우 데이터를 순회 함에 있어, 3가지의 인덱싱 방법이 있다고 합니다.

물론 우리의 선택에 따라도 되며 아니면 DBMS의 독자적으로 인덱싱을 하고 있습니다..

이 부분에서 자료구조시간에 배운 시간복잡도즉 오더의 수에 대한 고려가 필요한거라고 생각합니다만,

T-SQL문법자체는 C style의 신텍스에 비해 상당히 까다로운(DB만 전문으로 하시는 분들에겐 아닐수도 있습니다만 c/c++, C#등의 개발자인 저에겐) 구문을 가지고 있다고 보입니다.

예로 현재 DB에서 전담시키려고 하고 있는 Tree에 대해서 생각해보겠습니다.

그리고 개발 플렛폼은 MSSQL2000 + C#.NET 입니다.

C#은 UI와 3-Tier의 Application Domain의 역할을 하는 Domain을 위한 언어이고 나머지 데이터 처리는 DB의 Trigger나 SP에서 처리가 되고 있습니다

트리의 경우 이진트리와 일반트리와의 순회방식엔 (자료구조상엔) 상당한 차이(어찌보면 별거 아닌 차이)가 있습니다...

이에 대해선 모두가 아실거라 생각하고 예기를 풀어가겠습니다.

현재 화면에 트리를 그리거나 로직의 구동은 Post Order, 즉 후위순회방식을 채택하고 있었습니다

물론 C#의 클라이언트에서 DB에서 만들어주는 부모-자식관계에 대한 데이터셋(레코드셋)을 받아와 그리는 것 입니다.

현재 문제시 되는 것이 C#의 윈도우폼에서 구성되어진 알고리즘 자체를 웹솔루션의 필요로 인하여 ASP.NET으로 옮기는 컨트롤(라이브러리)을 만드는 과정에서 트러블이 발생한 것입니다.

비록 제가 DB에 대해선 LEFT Inner Join만을 사용하는 수준이지만, 아무리 생각하더라도 DB에 트리의 위치찾는 것 까지 전담 시키는 것은 데이터베이스에는 과도한 것이 아닌가 하는 것입니다.

첫번째 문제로는 .NET의 데이터셋의 네트웍 트래픽의 문제입니다.

이전 레코드셋의 경우엔 필요한 레코드집합만 불러오는 방식이었습니다.

허나 데이터셋의 경우엔 레코드의 집합 또는 테이블, 또는 뷰...등을 하나의 테이블의 모습으로 만들어진 상태로 전달되게 됩니다.

데이터가 바이너리든 아스키형태든...이 데이터는 기존의 레코드셋의 보완한 것이기는 하지만 DB서버와 서버데몬(Application Domain)이 다른 IP클래스 내에 존재하게 된다면 요청의 횟수에 따라 상당한 트래픽을 발생 시킬 거라 생각합니다.

이 문제의 경우엔 DB서버를 같은 클래스 내로 옮기게 되면 일단락은 시킬수 있으리라 생각합니다..

두번째 문제로는 오더(시간복잡도)의 문제입니다.

데이터셋을 받아오는 방식을 Fixed 시킨경우에, 클라이언트는 해당 서버에서 받아온 데이터의 집합을 가지고 화면에 트리를 출력하게 됩니다.

Tree의 구성은 바이너리 트리의 경우엔 연결 선을 그리기엔 무리가 적다고 볼 수도 있겠지만 바이너리 트리가 아닌 일반 트리의 순회법인 Post Order를 사용하는 수준에서는 각각의 노드들을 연결하는 연결선에 대한 알고리즘도 포함되어야 합니다.

즉 DB에서 노드들만 나열하기 위해선 일반적인 후위순회 알고리즘을 사용하여 나열이 가능합니다만, 부모 노드와 자식노드들 사이의 연결선을 찾기 위해선 또다시 노드들을 순회 해야하는 거라 보고 있습니다.

노드들의 위치만 판단하기에 n번의 시간복잡도가 생긴다고 가정하면, 제가 아는 한의 DBMS라면 n^x배의 시간복잡도가 더 늘어날 것으로 생각합니다.

그렇게 보면 클라이언트의 UI에 화면을 뿌릴때 노드의 갯수가 1000개라면 일단 1000^x개의 기하급수적인 오더가 늘어나게 되는데 DBMS가 만능이 아닌 한 여기에 대해선 노드의 수에 따라 DB의 트래픽이 가중될 거라 생각합니다.

물론 연결선에 대한 알고리즘도 SP내에 포함하여 다른 테이블 또는 뷰에 포함시켜 데이터셋으로 받아도 되리라 생각하지만,

그냥 부모-자식간의 관계를 정의한 데이터셋을 UI에서 받아 처리하는 것에 비해 그렇다할 확연한 차이를 보기는 어렵습니다.

UI에서 받아서 처리하는 식이라면 UI에서 받은 데이터로 노드를 그리면서 그 노드에 연결선을 자식이 다 그려지고 부모가 그려지는 시점에서 그려버리면 되니깐 말입니다.

저의 경우엔 Transaction을 Lock의 개괄적인 모습, Lock을 사용하는 것에 대한 것들을 형태화 시킨거라 보는 입장입니다. 이건 쉽게 이해하기 위함이기도 합니다.

COM, COM+이 Serialized한 Transaction을 가능하게 하기는 하지만 구지 DB의 트랜잭션을 빌리지 않아도, COM/COM+ 트랜잭션이 아니더라도 API자체의 스레드라던지 프로그래스바를 뿌려준다던지 하는 방법을 이용하여 Serialized 한 트랜잭션을 모방 할 수 는 있으리라 생각합니다, 이 것은 Select 쿼리를 사용하는 때에만 적용이 될 것이며, DB라던지 클라이언트의 어느 부분에도 값이 Update되는 부분이 없게 할 수 있기 때문입니다.

회사측에선 대부분의 분들께서 DBMS에 전문인이라 DB에 전임 시키자는 입장이지만

저의경우엔 이와 같은 경우엔 DB에 전임 시키게 되면 데이터베이스의 Utilize의 부분에서 상당히 반하는 거라 생각합니다.

그냥 UI의 API수준에서도 가능한 부분을 DB에 넘기게 됨으로써 DB의 빠른 처리를 바랄 수는 있겠지만, DB가 궂이 하지 않아도 되는 일을 시키는거 같아서 입니다.

여러분들의 의견을 듣고 싶습니다.

일단 저는 회사의 입장에 따라가야 하겠지만..

나중에 제가 다른 회사에 취업하여 팀장급 또는 프로젝트 마스터의 입장이 되었을때 선택해야 할 방법중 하나이기 때문입니다.

모두의 의견을 수렴하겠습니다..

저에게 도움이 될수 있도록 많으신 분들의 의견 부탁드립니다 ( __