취소 관련 테이블, 컬럼 설계 기준

컬럼을 추가할까? 아니면 별도 테이블로 나눌까?

• 장단이 있는데,
  • 컬럼은 나중에 추가 확장하기 쉽지 않다.
  • 테이블은 트랜잭션을 이용한 정합성을 신경써야 한다.
• 간단한 원칙 ) 1:1 관계이면 컬럼, 1:n 관계이면 테이블, m:n 관계이면 매핑테이블

사례 ) 카드 발급과 관련된 비용 결제 정보를 카드 발급 테이블에 컬럼으로 추가할지? / 아니면 별도 테이블로 분리할지?

• 비용 결제가 딱 1건만 일어나서 카드 발급 건과 1:1 관계인 경우, 컬럼으로 추가해도 무방하다.
• 비용 결제가 다양한 사유로 n번 일어날 수 있거나, 지금은 아니더라도 향후에 다른 결제 사유가 추가 되어 1:n이 될 수 있는 구조라면, 테이블 분리하는 것이 옳다. 결제 사유가 추가 될 때 마다 컬럼을 추가하는 것도 어색하고, 낭비가 심하다.

취소 관련 테이블 설계 사례

• 원건과 그에 대한 취소가 발생하는 상황에서, 원건과 취소건의 저장 구조에 대한 선택지는 크게 3가지다.
  • 1안. 컬럼으로 구분 (원건 컬럼 + 취소건 컬럼)
  • 2안. row로 구분 (원건 row + 취소건 row)
  • 3안. table로 구분 (원건 table + 취소건 table)

최적의 선택지는 상황과 요구사항에 따라 달라지며, 엔티티를 바라보는 관점의 차이가 핵심이기 때문에 해당 엔티티가 표현하는 실세계의 개념을 정확히 이해해야 최적의 설계를 식별 할 수 있다.

1안. 컬럼으로 구분 (원건 컬럼 + 취소건 컬럼)

원건+취소건을 하나의 엔티티로 본다는 의미가 있다. (e.g., ‘거래’라는 엔티티 안에 원건 속성과 취소건 속성이 동시에 존재한다.)

• 원건과 취소건이 1:1 관계 일 때만 사용 할 수 있다. 1:n 일 때는 사용 할 수 없다.
• 취소건 일 때 추가되는 컬럼이 거의 없을 때 유용하다.
• 취소건이 원건에 완전히 종속적이고 발생 확률이 매우 높을 때 유용하다.
• 취소건과 원건이 거의 대부분 함께 조회되어야 한다면, 원건/취소건을 1번의 쿼리로 한 번에 가져올 수 있다.
• 기본적으로 컬럼 기반의 설계는 확장성이 떨어지는 편이다.

2안. row로 구분 (원건 row + 취소건 row)

원건, 취소건 구분 없이 같은 엔티티로 본다는 의미가 있다. (e.g., 둘 다 똑같은 ‘거래’다)

• 원건 일 때 저장해야 하는 정보와, 취소건 일 때 저장해야 하는 정보가 큰 차이가 없을 때
• 즉, 원건과 취소건의 컬럼이 거의 동일해서 비어있는 컬럼이 거의 없을 때 유용하다.
• 원건과 취소건이 1:n 관계 일 때도 사용 할 수 있다.

3안. table로 구분 (원건 table + 취소건 table)

원건, 취소건을 완전히 별개의 엔티티로 본다는 의미가 있다. (e.g., ‘원거래’라는 엔티티와 ‘취소거래’라는 엔티티는 서로 별개의 엔티티다.)

• 원건과 취소건이 1:n 관계 일 때도 사용 할 수 있다.
• 원건 일 때 저장해야 하는 정보와, 취소건 일 때 저장해야 하는 정보 사이에 차이가 클 때 유용하다. (테이블 스키마가 크게 달라야 할 때)