Three Rules for Database Work

하루에 10만을 채우는 게임은 이런 게 이벤트가 되는구나.

오늘자 코드 프로젝트에 올라온 DBTool의 근간이 된, 데이터베이스를 갖고 놀 때의 세가지 룰은 생각보다 간단했다.

Never use a shared database server for development work.

예전에는 (rails 스타일의) development-test-production 의 3단계 구분법을 사용했다. DBA와 서버 프로그래머는 dev DB에서 열심히 뒤집어 엎어도, test DB에 연결된 다른 프로그래머들이나 테스터들은 안정적으로 사용할 수 있고, 실제 서비스는 production 데이터베이스를 쓰게 된다는 거다.

Always Have a Single, Authoritative Source For Your Schema

DB 에 짧지만 단순한 나의 지론은, 레파지토리 어딘가에 무조건 전체 스키마+초기데이터를 담은 SQL 파일을 두고 버전 관리를 해야 한다는 거다. 소스 코드, 애셋들은 과거의 특정 시점의 스냅샷을 꺼내올 수 있는데, 유독 데이터베이스가 열외일 수는 없다고 본다.

또한 어차피 데이터베이스 패치를 해야 할 테니, create, alter로 가득찬 DB 패치 스크립트도 버전 관리해야 한다. test -> production 를 업그레이드할 때 모두 지우고 새로 만드는 만행을 할 수 없을테니, 아예 dev -> test 에서부터 미리 스크립트를 만들어서 테스트하면 정신 건강에 좋지 않겠냔 말이다. 처음에 언급한 DBTool 이 이런 걸 자동화해주는 모양이다.

Always Version Your Database

보통은 Config 테이블에다가 문자열로 데이터베이스 스키마 최종 변경일을 넣어두는 걸로 해결하고 있다. 그런데 아직 뭔가 변경이 잘 되었는지를 체크할 만한 테스트를 만들 능력은 안된다. 대체로 alter 든 drop 이든 서버가 뜰 때까지는 잘 모를것 같아서.. :)

이 외에도 무시무시하게 긴 Better SQL Server Databases 라는 규칙도 있는데 이건 좀 귀찮구나....

추가:

• 다른 글을 찾아 보니, 프로시저나 테이블 각각을 서로 다른 파일에 저장해서 관리하라는 말도 있다. 은근히 그럴듯한데?