[DB] 테이블 설계 시 주의사항 (사례)

테이블 설계를 할 때는 정말 많은 것들을 고려한다. 시중에 나와 있는 책을 보면 두꺼운 책으로 몇 권을 설명할 정도로 가벼운 양이 아니다. 배운 내용들에 대해서 그리고 실무를 통해서 생각했던 것들에 대해서 틈틈이 정리를 해보자.

 

1. 테이블 설계를 충분히 고려하지 못했을 때

거래 시스템을 설계한다고 보자. 테이블 설계 시 거래를 발생시킬 수 있도록 거래 테이블을 설계되었다. 거래가 발생하여 거래 테이블의 차곡차곡 데이터가 쌓이고 있다. 하지만 문제점이 있었다. 거래 발생 시 구조상 거래는 당사의 계약정보와 금액이 달라도 거래가 발생되게끔 되어 있는데, 계약정보와 다르게 금액이 발생하고 있었던 것이다. 8천 원 물건을 잘못된 쿼리 문제로 1만원에 거래가 발생되고 있었다. 발생한 거래에 대해서 수정하기 위해 UPDATE를 시도를 했지만 거래 테이블의 거래 품목의 대한 정보가 없어 문제의 거래들을 찾아낼 수 없었다. 문제 발생 시 정산까지 고려를 하지 못해 거래 데이터가 잘못되어도 건을 찾을 수 없는 문제가 발생했다. 문제 발생 찾는 시기도 지연이 되었는데 또 다른 문제가 검수 로직이 부족하여 거래 발생과 계약정보의 따른 검수 로직이 부족한 것을 확인하였다.

 

- 테이블 설계 시 정산까지 고려 부족 (정산 마인드를 갖추자)

- 검수 로직 부족

 

2. 테이블 설계를 충분히 고려하지 못했을 때

프로모션을 기획하게 되었다. 거래가 발생할 때 건에 대해서 프로모션을 적용을 하게 되는데 프로모션 금액도 별도로 관리하게 된다. 처음 기획할 때 프로모션이 하나여서 하나만 적용할 것으로 생각이 되었는지 금액 칼럼을 하나만 만들었 던 것이다. 하지만 프로모션이 여러 가지 생기면서, 생길 때마다 컬럼을 추가하고 영향범위에 포함된 시스템의 수정 개발 작업이 들어간다. 최초 개발할 때 프로모션이 여러 개 생길 것으로 고려했다면 프로모션 종류 컬럼 그리고 금액 컬럼을 만들었을 것이다. 그렇게 된다면 새로운 프로모션이 발생해도 코드값만 추가하고, 컬럼 작업 그리고 수정 개발을 할 필요는 없어진다.

 

이미 만들어진 데이터베이스 구조는 바꾸기가 쉽지 않다. 수많은 시스템에 연계되어 있기 때문에 구조를 바꾸게 되면 시스템 전체가 흔들리는 일까지도 발생할 수 있고, 영향범위가 넓어 섣불리 변경할 수 없다.