엔터티 통합하기

요사이는 테이블들을 합칠지 말지 하는 고민을 많이 하고 있습니다.

언뜻 보기에는 테이블의 데이터들이 유형만 다를 뿐 비슷해 보이기는 하는데, 속성을 하나하나 뜯어 보자니 좀 다른것 같기도 하고... 참 결정하기 힘든것 같습니다.

예를 들어 도서관에서 책을 구매하고자 하는 대상을 모아놓는 테이블이 아래와 같이 여러 종류가 있다고 해볼께요.

<그림1. 다양한 구매 대상 테이블>

속성이 조금씩 다르기는 하지만 의미상으로는 같은 구매 대상이기 때문에 통합하고 싶습니다.

좋은 결정을 내리기 위해서는, 통합 했을때의 장단점을 하나하나 따져보는 수밖에 없을것 같아요.

일단 장점을 살펴보자면, 

실제로 주문을해서 구매를 진행하게되는 이후 프로세스 처리 시 에는 다 같이 사용될 확률이 높은데, 통합하면 데이터 모델이 단순해집니다.

예를들어 통합전에는 모든 구매신청 테이블이 주문으로 통합되는 아크(arc) 관계를 가져야 하는데, 하나가 되면 하나의 관계로 표현하게 되니까요.

<그림2. 분할된 구매 신청의 이후처리 관계>

<그림3. 통합된 구매의 이후처리 관계>  

그리고, 또한가지 장점은, 

개발의 측면에서는 화면에서 전체 구매신청 내역을 보여준다거나, 혹은 집계 처리를 하고자 할때, 모든 유형의 구매 테이블을 조회해서 통합 해주어야 하는 - SQL 같으면 union all 을 사용한다든지 - 일이 발생할 텐데, 통합하면 이런 처리가 매우 단순해진다는 점입니다. 

그렇다면 통합을 했을때의 단점은 어떤것이 있을까요?

일단 한 테이블에 모두 모아놓으면 데이터의 건수가 많아지겠네요. 이에따라 조회 성능이 떨어질 수 있구요. 이 외에도 입력이나 수정을 위한 트랜젝션이 몰려서 작업 시간이 오래 걸릴 수도 있습니다.

 

그리고 업무 규칙이 가시적으로 드러나는 면이 약해 집니다. 

예를 들어 통합전에는 회원의 신청에 의한 구매나 노후도서에 대한 교체구매에 대해서 명시적인 관계를 맺어주게 되고, 다른사람이 봐도 이것을 이해할 수가 있는데요.

<그림4. 분할된 구매 신청의 부가관계>

통합해놓고 나면 이게 명시적으로 드러나지 않기 때문에, 데이터 값을 조회해보고 안다든지, 응용 프로그램 소스를 보고 알아낸다든지 해야할 확률이 높아집니다.

<그림5. 통합된 구매 신청의 부가관계>

이러한 고민을 충분히 해보고 통합여부를 결정해야 합니다.

그리고, 통합을 하기로 결정한 경우에도, 통합의 수위도 조절할 수 있겠지요.   

지금의 예제에서는 전체를 하나로 통합 할수도, 적절히 나누어 통합 할수도 있습니다. 

<그림6. 다양한 수준의 통합>

윗줄처럼 신청에 의한것과 아닌 것으로만 통합할 수도 있고, 좀 더 세분화해서 외부기관 선정만 통합할 수도 있습니다. 물론 지금까지 얘기해왔던대로, 아예 하나로 통합 할 수도 있겠지요.

금주에 제가 고민한 상황에서는, 통합의 장점을 누리기 위해서는 확실하게! 통합해버리는 - 하나로요 - 것이 괜찮은 방법인것 같습니다.   All or Nothing ? 모 아니면 도? :-)