セッションで 「テストデータの管理がプロジェクトの成否に大きく関わる」 と主張させて頂きました。 丁度、同じ時間に似たような問題領域を題材に別のアプローチの 解決を提示されていたツールがありました。 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はまだ # ニーズがあるのかな!?!? # (利用者の方いらっしゃるみたいですし) #