중간에서 멈추는 DDL 스크립트

스키마 파일을 열었더니 테이블을 전부 지우고 다시 만드는 구성이었다. 지우는 문장에 존재 여부를 확인하는 절이 붙어 있지 않았다.

Open Table of contents

지우고 다시 만드는 스크립트

없는 테이블을 지우려 하면 오류가 나고 스크립트가 거기서 멈춘다. 클라이언트 설정에 따라 이후 문장이 계속 실행되면 오히려 더 나쁘게 일부만 반영된 상태가 된다.

새 환경에 처음 적용할 때는 테이블이 하나도 없으니 첫 문장부터 실패한다. 중간에 테이블이 추가된 뒤에도 목록에 없는 것은 안 지워지고 옛 구조 그대로 남는다.

존재할 때만 지우는 절을 붙이면 몇 번을 돌려도 같은 결과가 나온다. 한 단어가 스크립트의 성질을 바꾼다.

한 번만 되는 스크립트는 실행 전 상태에 의존하므로 실패하면 손으로 정리해야 하고 재실행 가능한 스크립트는 상태와 무관하므로 실패해도 다시 돌리면 된다. 배포가 중간에 죽을 수 있는 자리에서는 뒤쪽만 쓴다.

지우는 순서가 알파벳순이었는데 외래키가 없어서 지금은 문제가 없다. 참조되는 테이블을 먼저 지우면 실패하므로 외래키가 생기면 이 스크립트가 깨진다.

그때는 역순으로 지우거나 제약을 잠시 끄는 방식이 필요하다. 지금 안 걸린다는 것과 앞으로 안 걸린다는 것은 다르므로 그 사실을 주석으로 남길 자리였다.

파일명이 스키마 정의라는 뜻만 담고 있어서 초기화용인지 마이그레이션용인지 알 수 없었다. 받는 사람이 스키마 파일로 보고 운영에 돌리면 전 테이블이 날아간다.

이름이 용도를 말하게 하고 파괴적인 스크립트에는 첫 줄에 경고가 붙게 했다. 개발 환경 전용이고 전 테이블을 지운다는 문장이 파일을 열자마자 보이게 했다.

같은 파일에서 컬럼이 대체로 빈 값을 허용하게 정의돼 있는 것도 봤다. 필수 여부가 데이터베이스에 없고 애플리케이션 검증에만 있는 상태였다.

들어오는 경로가 하나가 아니므로 검증을 거치는 경로와 안 거치는 경로가 섞인다. 나중에 제약을 걸려면 이미 빈 값인 행을 먼저 채워야 하는데 무엇으로 채울지 모르는 경우가 대부분이라 필수 제약은 처음에 거는 것이 가장 싸고 정말 필수인 몇 개만 골라야 한다.