データベースの進化的設計
こないだのSeasar Conferenceでデータベースの進化的設計というのが印象に残ったのでオブラブで公開されてる日本語訳を読んでみた。
自分はDBFluteを使っているので、その観点でまとめ。
DBAは開発者と密接に協力し合う
みんな協力してがんばろうというお話。
社内に壁作れないほど小さいうちみたいなとこには関係ないかも。
ITゼネコンでなければ自社内にDBAもアーキテクトも開発者もいるんじゃないかな。
特にDBAが決まっていない場合もあるだろうけど、各開発者が勝手にスキーマ変更しだすと収集つかないので、最終的に反映する人、っていうのは決めた方がいいと思う。
全員が自分のデータベースインスタンスを保有する
これは必須の要件だと思った。テストするときにデータを変更するなんてしょっちゅうだし、ちょっと試しにインデックスを張りたくなったりを、いちいちDBAに依頼しなきゃいけなかったりするのは面倒。
その変更のせいで他の開発者に影響が出るようなことがあっても困るので、開発者は自分のDBインスタンスを持つべき。
開発者は共有マスターに頻繁に結合する
共有マスターというのは、どっかで管理されてる最新のDBモデル(DDL文)と理解。
各開発者は、最新のスキーマを1日1回は反映しようということと、スキーマの変更はDBAに相談しましょうというお話。
まとめて大きな結合を1回するよりも、細かい結合を繰り返した方が行いやすいというのは同感。
スキーマとテストデータから成るデータベース
DDLだけじゃなくデータも一緒に管理しましょうというお話。
DBFluteならUT/IT/STなど用にそれぞれ別のディレクトリでExcel/Csv/Tsvを管理できるのでいい感じ。
DBFluteを使う前、Unitテストの各テストメソッド毎にExcel読み込んだりしてたけど、
replace-schemaでUT用のデータを流し込んでおいて、それを使ってUnitテスト書く、という風にしたのでテストが早い早い。
CIサーバーで最初にreplace-schemaしてからビルド流すようにすれば、データベースとコードの間で不一致が起きてないかいつも確認できるようになるのでオススメです。
あとここでは、データはなるべく実データを使いましょうということも言っている。実データの方が例外ケースの発見に役立ったりするそう。
すべての変更でデータベースのリファクタリングになる
リファクタリングを自動化する
すべての開発者のデータベースに変更を自動的に適用する
データベースのリファクタリングがコードのリファクタリングと大きく異なる点は、同時に行うべき三つの変更が含まれていることだ。
* データベーススキーマの変更
* データベース内のデータの移行
* データベースアクセスコードの変更
テーブルスキーマを変更には、カラム追加のような小さなものと、カラム削除、制約追加のような「破壊的な変更」がある。
いずれにせよ、現時点ではDBFluteもJiemamyも、スキーマ変更をデータベースに反映するのは「DROP-CREATE-INSERT」なので、結局のところデータは破壊されてしまう。
ここが解決できないと、リファクタの自動化、DBへの自動反映はむしろ有害。
データベースアクセスコードを明確に分離する
DB変更の影響範囲を見極めるため。
DBFluteならコードは自動生成なので勝手に変更してくれるし、変更の結果動かなくなるところはコンパイルエラーになるのですぐ修正できる。
S2JDBCだと文字列で指定するところがあるので、修正漏れるだろうなぁ。。S2JDBC-Genを使っていれば同じくコンパイルエラーになる。
大体こんな感じ。
やっぱりALTER文が欲しいという結論に変わり無し。