전용 테이블을 공용으로 바꾸는 일

작업 일정표를 받았다. 맨 첫 줄이 DB 작업이다.

Open Table of contents

배경 — 일정표 첫 줄의 DB 작업

첫 줄은 이렇게 적혀 있다.

특정 카테고리 전용 테이블 → 예외 항목 공용 테이블로 변경 및 컬럼 추가

하루짜리 작업으로 잡혀 있다.

일정표의 나머지는 화면 작업이다.

관리 화면 스무 곳 남짓
각각 배너·상품·기획전 등록

스무 곳이 전부 이 테이블을 쓴다. 그래서 이 줄이 맨 앞에 있는 것으로 보인다.

배너와 상품과 기획전이 전부 같은 deal 표를 읽고 쓰는 구조다. 표 하나의 구조가 화면 스무 곳의 전제가 되어 있는 셈이다.

DB와 화면 중 어느 쪽을 먼저 하느냐는 사실상 정해져 있다.

[DB 먼저]  화면 작업이 새 구조 위에서
[화면 먼저]  옛 구조로 만들고 나중에 전부 고침

화면을 먼저 만들면 스무 곳을 두 번 손대게 된다.

일정 맨 앞의 하루가 뒤쪽 스무 줄의 전제라는 뜻이다. 이 하루가 밀리면 뒤가 통째로 밀리거나 옛 구조 위에서 시작된다.

옛 구조 위에서 만든 화면은 deal_type 이 생긴 뒤에 스무 곳을 다시 열어야 한다. 일정표가 DB 작업을 첫 줄에 둔 것은 그 재작업을 피하려는 배치로 읽힌다.

원래 이 테이블은 특정 카테고리 전용이다.

일반 상품   기존 구조
그 카테고리  전용 테이블

그 카테고리만 다른 처리가 필요해서 예외를 별도 테이블로 푼 것으로 보인다.

이번에 예외가 하나에서 여럿으로 늘었다.

[전]  예외가 하나
[후]  예외가 여럿

예외가 늘면 앞의 해법이 그대로는 안 늘어난다. 하나였을 때 맞던 구조가 여럿이 되면서 다시 선택 대상이 된 것이다.

처음 만든 사람이 잘못 고른 것으로 보기는 어렵다. 예외가 하나일 때는 전용 표가 가장 단순한 답이고 그때의 조건에서는 맞는 선택이었다.

갈림길은 둘이다.

[전용 테이블을 또 만든다]  예외마다 테이블 하나
[공용으로 바꾼다]          구분 컬럼을 두고 한 테이블

일정표는 뒤쪽으로 적혀 있다.

전용을 계속 만들면 표가 이렇게 는다.

테이블 A (카테고리1 전용)
테이블 B (카테고리2 전용)
테이블 C (카테고리3 전용)

조회할 때마다 어느 표인지 분기해야 하고 목록을 합쳐 보여주려면 UNION 이 붙는다. 표가 늘면 그 쿼리도 따라 는다.

공용이면 조건 하나로 끝난다.

WHERE deal_type = ?

유형이 하나 더 생겨도 이 조회는 그대로다. 화면이 스무 곳이라는 점에서 이 차이가 커 보인다.

UNION 쪽은 표가 하나 늘 때마다 그 쿼리를 쓴 화면을 전부 찾아 고쳐야 한다. 스무 곳 중 어디에 그 쿼리가 있는지를 다시 찾는 일이 매번 붙는다.

대신 공용은 컬럼이 는다.

카테고리1에만 필요한 컬럼
카테고리2에만 필요한 컬럼

서로 안 쓰는 컬럼이 NULL 로 남고 일정표의 컬럼 추가가 그 이야기로 보인다.

어느 쪽이 나은지는 예외의 개수에 달린 것 같다.

[예외 하나]    전용 테이블이 깔끔
[예외 여럿]    공용이 낫다
[예외 아주 많음]  값으로 빼는 구조를 봐야 함

정보고시 항목을 볼 때와 같은 갈림길인데 거기는 카테고리가 수십 개여서 값으로 빼는 쪽이었다. 여기는 예외가 몇 개 수준이라 아직 그 정도는 아닌 것으로 보인다.

다만 예외가 계속 는다면 NULL 컬럼도 같이 늘어난다. 컬럼 수가 어느 선을 넘으면 같은 갈림길이 한 번 더 온다는 뜻이다.

일정표에 안 적혀 있는데 따라붙는 것이 있다. 전용 표의 기존 행을 공용 표로 옮겨야 한다.

전용 테이블의 행들
    ↓
공용 테이블로 (구분 컬럼에 값을 채워서)

그 표의 id 를 들고 있는 다른 표도 있을 것이다. 옮기면서 id 가 바뀌면 그쪽도 함께 고쳐야 한다.

id 를 그대로 가져가는 길이 있다.

INSERT INTO deal_common (id, deal_type, ...)
SELECT id, '<구분값>', ... FROM deal_tour;

자동 증가를 잠시 무시하고 값을 지정해 넣으면 참조하는 쪽을 안 고쳐도 된다.

여러 전용 표를 합치는 경우라면 id 가 겹칠 수 있다. 겹치면 매핑표를 만들어 참조를 전부 갱신하거나 표마다 시작값을 떨어뜨리는 길인데 뒤쪽은 나중에 구간이 만나면 다시 문제가 된다. 이번은 표 하나라 겹칠 일이 없어 보인다.

하루라는 일정이 맞는지는 규모를 보면 갈린다.

SELECT COUNT(*) FROM deal_tour;

옮길 행이 적거나 참조가 없으면 하루가 맞을 수 있다. 행이 많으면 한 번의 INSERT ... SELECT 가 원본 표를 오래 잠그므로 끊어서 옮기는 시간이 따로 든다.

옮긴 뒤 원본을 바로 지우면 대조할 것이 없어진다. 이름만 바꿔 두고 확인이 끝난 뒤에 정리하는 단계가 일정표에는 안 보인다.

옮긴 행 수가 원본과 같은지를 나중에 확인하려면 원본이 남아 있어야 한다. 하루짜리 줄 하나에 이관과 참조 갱신과 대조까지 들어 있다면 그 하루는 표 만드는 시간만 잡은 것으로 보인다.