화면이 만든 것과의 대조

계정을 여러 개 만들어야 했는데 화면으로 하나씩 하면 오래 걸릴 분량이었다. 스크립트로 직접 INSERT 하기로 하고 MySQL 의 어느 표에 무엇이 들어가는지부터 살폈다.

Open Table of contents

상황 — 여러 계정과 직접 삽입
스키마만 보고 짠 초안
여섯 개 필드가 달랐다
역참조와 조건부 필드
한 건 대조의 비용
정리

상황 — 여러 계정과 직접 삽입

관련 표가 넷이었고 외래키로 이어져 있었다.

설정 테이블
  ↓ FK
계정 테이블
  ↓ FK
클라이언트 테이블
  ↓ FK
카테고리 계정 테이블

DESC 로 스키마를 읽으면서 컬럼별로 무엇을 넣을지 초안을 채웠다.

INSERT INTO configs (use_import, change_date, ...)
VALUES (1, 60, ...);

use_import 는 1, 나머지 플래그는 0, 기간은 60, 이름은 채널명 그대로였다.

컬럼 이름과 타입과 DEFAULT 를 보면 대부분은 채울 값이 짐작됐다. 그런데 짐작으로 채운 값이 맞는지는 스키마 안에 답이 없었다.

스키마만 보고 짠 초안

그래서 초안을 바로 돌리지 않고 화면으로 계정을 하나 만들어 봤다. 화면이 만든 레코드가 정답이므로 그것과 내 초안을 대조하면 된다.

화면으로 만든 것을 SELECT 로 뽑아 초안과 나란히 놓고 봤다.

컬럼              내 초안    화면 생성
─────────────────────────────────────
use_import          1          1     ✓
use_export          0          1     ✗
use_orders          0          1     ✗
use_claims          0          1     ✗
use_cs              0          1     ✗

대조 자체는 몇 분이면 끝나는 일이었다.

여섯 개 필드가 달랐다

여섯 개가 달랐고 그중 넷이 use_ 로 시작하는 플래그였다. 나는 기본이 0이라고 봤는데 화면은 전부 1로 넣고 있었다.

나머지 셋 중 둘은 코드 값이었는데 내가 넣으려던 것과 다른 값이 들어 있었다. DEFAULT 와 화면이 실제로 넣는 값이 서로 다른 자리였다.

역참조와 조건부 필드

마지막 하나는 상위 표의 컬럼이 새로 만든 하위 행의 식별자를 가리키는 자리였다. 하위를 INSERT 하고 나서 상위를 UPDATE 해야 하는데 그 순서는 스키마에 안 보인다.

조건부로 채워지는 필드도 하나 있어서 다른 값에 따라 넣을 값이 달라졌다. 고정값으로 박아 뒀으면 어떤 계정에서는 맞고 어떤 계정에서는 틀렸을 것이다.

한 건 대조의 비용

INSERT 는 틀린 값이어도 성실히 들어가고 오류를 내지 않는다. 그래서 돌린 뒤에 확인하려면 어디가 틀렸는지 스스로 찾아야 한다.

화면으로 한 건 만들어서 대조하는 것이 그 확인을 가장 싸게 하는 방법이었다. 한 건이면 충분하고 그 한 건이 여섯 개를 잡았다.

정리

직접 INSERT 하는 스크립트는 화면이 만든 행과 대조한다
스키마만 보고 채우면 그럴 것 같은 값이 들어간다
INSERT 는 틀린 값도 성실히 넣고 성공한다
플래그가 전부 켜지는 것이 기본일 수 있다
DEFAULT 와 화면이 넣는 값이 다르다
하위 INSERT 뒤 상위 UPDATE 순서는 스키마에 안 보인다
조건부 필드는 다른 값에 따라 결정된다
대조는 레코드 한 건이면 되고 그것이 가장 싸다