DBの管理について

最近の開発は、DBがコロコロ変わることが多い。
こと、XPだのだとそれが当たり前なので、管理することが必須だ。

管理といっても、私が携わってきたプロジェクトでは、定義書(エクセル)からDDLを生成することくらいしかしていなかった。
つまるところ、新しくテーブルを作る場合は、
ドキュメントとして定義書を作成→レビュー
という流れとなる。
つまり、レビューのために見やすい(日本語名やコメントがしっかりと書かれた)ドキュメントが必要なため、当然の結果と言える。
テーブルの変更については、あまり考慮されていないことが多いよう。

全員が全員SEなら、これでも別に問題ない。(というかそんなに問題になったことはない)
動かしてみれば、カラムが無いと怒られるのだから、その時に最新のドキュメントを参照し、個々人がローカルDBに直接手を加えれば良い。

私が驚いたのは、Railsだ。
マイグレーションという何とも妙な機能があるではないか。
このマイグレーションが素晴らしい。

DDLは一切書かず、すべてRubyでDB定義をしてしまおう。そしてそして、その変更までもを管理してしまおうという壮大なものだ。
このアプローチはRails業界ではかなりの成功を収めているように思う。
開発者がいればいるほど、このマイグレーションは素晴らしく機能する。
新規開発者の環境構築は驚くほどスムーズになる。
(Railsが動く環境さえ作ってしまえばそれでいいのだから。)

さて、このマイグレーション。実はそんなに難しいものではない。(DDLを言語で表現するのを別にすれば)
ようは、現在DBのマイグレーションのバージョンがいくつかを管理するための機構とマイグレーションを実行するスクリプトがあればこと足りる。

マイグレーションの管理は、カラムが一つ(int型)のテーブルを用意して、そこに現在のバージョンを書き込んでやれば良い。
簡単な実装なら、
生のSQL文(ALTERとか)を連番で管理(ファイルね)してやり、
現在のマイグレーションバージョンより新しいファイルがあれば、順次適用することができれば良い。
(必要なら、更新ファイルとペアで戻すALTER文も管理してやればいい)

これがあるだけで、他の開発者のDB更新作業というのは非常に楽ちんになる。
複数人が同時にテーブル変更した場合でも、一発で最新になってしまうのだから。
(私は忘れっぽいので、mysqlのDB名やらログインIDやらを覚えていられないのだ。なのでパッチを当てるだけでも結構手間どうことがあったりする)
ということで、この方法は他の言語でも実装すべき。
私は多言語で実装したことがあるが、1時間くらいで実装できた覚えがある。