ReplaceSchemaの思想

セッションで
「テストデータの管理がプロジェクトの成否に大きく関わる」
と主張させて頂きました。

丁度、同じ時間に似たような問題領域を題材に別のアプローチの
解決を提示されていたツールがありました。
S2JDBC-Genです。当日それに関する質問もありましたので、
ここに簡単に書かせて頂きます。

https://event.seasarfoundation.org/sc2008autumn/Session#a1
の資料の丁度「9ページ」がよくわかるところです。
S2JDBC-Genは右側の開発運用を実現するアプローチを取られています。
それに関する詳細な説明は別のページにあるので割愛します。

一方、DBFluteは左側の開発運用のやり方は今までと変わらず、
そのやり方をより向上させるアプローチを取ります。

ReplaceSchemaのような機能を使うことによって、プログラマへの
展開をより速くより安全にするというアプローチです。
詳細はReplaceSchemaの機能を見て頂ければわかるかと思います。
https://event.seasarfoundation.org/sc2008autumn/Session#c1

また、DBFluteの機能でどうのこうのやるわけではありませんが、
思想的には「DDLはERDツールから自動生成」を推奨しています。
これはドキュメントドリブンな考え方で、ERDのドキュメントとしての
「寿命の長さ」・「コミュニケーションの資料としての重要度」
を重視しての方式です。
DBがアプリより長生きなのと同じで、ERDは次期システム移行後も
生き続けるドキュメントである可能性が高いです。
そしてリリース前もリリース後も人と人がシステムを議論するための
重要なドキュメントです。次期システム移行の現状分析・論理設計時
にも利用されます。
個人的には、ERDを書いてない、もしくはERDとDDLがズレてる(可能性がある)
場合は、「いますぐERDツールを買って図を書いてDDLを自動生成しましょう」
という思いがあります。それほどのERDは重要と考えております。

こういったツール(ReplaceSchema & ERDツール)の利用によって、
現状のスタイルのまま向上しようというアプローチです。
また、ツールを使って手順を単純化することによって、
DBAがいない場合も別の人が代理して作業ができるようになります。
(自分の周りのプロジェクトではこの方式でやることにより、
 以前に比べてはるかに開発がスムーズに進むことを実感しております)

結論的には、どちらがよいというわけではなく、現場にとって
選択肢が増えたということが非常に良いことだと思います。

#
# 上記と直接関係ないですが、
# 会場でid:taediumさんと色々お話できて非常に光栄でした!
# 今後もお互い頑張りましょう!
#

#
# 追記:
# そういう意味では、DBFlute for S2JDBCはまだ
# ニーズがあるのかな!?!?
# (利用者の方いらっしゃるみたいですし)
#