Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to 20120830 DBリファクタリング読書会第三回
Similar to 20120830 DBリファクタリング読書会第三回 (20)
More from 都元ダイスケ Miyamoto
More from 都元ダイスケ Miyamoto (20)
Recently uploaded
Recently uploaded (10)
20120830 DBリファクタリング読書会第三回
- 2. 自己紹介 • 都元ダイスケ (@daisuke_m) • Java屋です • java-jaから来ま(ry Java オブジェクト指向 Eclipse 恭ライセンス 薬 Mahout Spring XML Jiemamy DDD HadoopOSGi Haskell Scala Maven Wicket AWS 酒
- 3. works • @IT Database Expert 2008年9月 • 日経ソフトウエア • Java入門記事 • Eclipse記事
- 4. • というOSSプロダクトを作っていま(す|した) • 2006年頃から…。 • 軽い気持ちで始めたら、重いテーマだった。 • 正直、欲張り過ぎて手どころか頭も回らな くなったプロダクトがこちらになります。
- 6. 今日のポイント • Jiemamyで実現したいこと • ひとまず実現できたこと 実現できそうなこと • 実現に際して大きな困難が伴うこと • Jiemamyが止まってしまったその他の理由
- 7. DBの 進化的設計 Evolutional Database Design — Martin Fowler and Pramod Sadalage, 2003 http://www.objectclub.jp/community /XP-jp/xp_relate/evodb-jp データベース リファクタリング
- 9. Evolutional DB Design • 実装前に設計を確定させるのは、もは や不可能（→アジャイル） • DBの設計に関しても同様で、リファク タリングを適用したい • しかし、DBはアーキテクチャの低層に 位置しているため、被依存度が高く、 変更しづらい • どーする？
- 10. not only refactoring • DB変更はrefactoringだけではない • テーブルやカラムの追加や削除 • 開発中のDBの変更履歴・構成管理
- 11. あらためてJiemamy • DB構成情報を１つに集約 (smart model) 「重要なことはファイルを扱うようにデータベースを扱えるツールを持つことだ。」 「スキーマとテストデータから成るデータベース」 • データファイルをVCS管理 (smart version control) 「マスターデータベースをソースコードと同様に構成管理の下に置くのである。」 「全システムを管理する強力な構成管理ツールの下にあれば、もし最悪の事態が起こっても元に戻すのは難 しいことではない。」 • ビルドフェーズでDB整備 (smart build) 「すべての開発者のデータベースに変更を自動的に適用する」 ∼ツール面からDBの進化的設計をサポート∼
- 13. smart model • DBの構成情報を知っている唯一の存在 • この情報を元に、派生データを作る • DDL / テストデータDML • DB設計書 • ER図 • データアクセスコード（エンティティ等）
- 15. smart version control class Emp { String name; Busyo busyo; } class Busyo { String name; // ... } class Dept { String name; // ... } class Emp { String name; Dept dept; }
- 16. smart version control CREATE TABLE HOGE ( ID integer ... ); @Table("HOGE") class Foo { // ... } @Table("FOO") class Foo { // ... } CREATE TABLE FOO ( ID integer ... ); 要は、チェンジセットを意識しなさいって話
- 17. smart build • 一般的に、プロダクトをVCSからcoして きてもすぐに動かせない • DB環境の整備が必要 • ビルドフェーズでDB整備 • Mavenプラグイン
- 18. smart deploy? • デプロイ時に、自動的にDB変更 • ServletContextListener • ちょっと恐い → どうすればいい？
- 19. 設計にあたって • データファイルはVCSにコ ミットしてdiff / mergeできる べき（バイナリ不可） • データファイルからDB環境 を自動構築できるべき • スキーマだけではなく、テス トデータも管理できるべき • 多くのRDBMSで使えるべき • 外部システムがこのデータを 利用できるように、安定して 使いやすいAPIを提供すべき • DB変更内容を検知し、 ALTER文等にマッピングでき るべき • データアクセスコードもリファ クタリングに追従すべき
- 20. Jiemamy components jiemamy-core jiemamy-commons apache commons jiemamy eclipse plugin maven-jiemamy-plugin jiemamy-diagram jiemamy-sql DiagramEditor TableView DbObjectEditPart ExecuteMojo JmDiagram JmNode / JmConnection SqlStatement Token JmTable / JmView JmColumn JmForeignKeyConstraint SqlExecutor / UUIDProvider woodstox XMLInputFactory XMLValidationSchema UI Application Domain Infrastructure
- 22. diffとmergeが可能 • データ形式にXMLを採用 • きちんと整形し、diff / mergeに対応 • 手で編集する以上、補完も必要
- 23. XML Schema
- 25. diffモデル • 2つのDB状態を compare/diff して、 DB変更モデルを作る • 変更モデルがALTER文にマッピング でも実際、diff のアルゴリズムは大変です。
- 26. リファクタリング自動化 • テーブル名・カラム名を変更した時 • テストデータのDMLも変更 → OK • データアクセスコードを変更 @Table("FOO") class Foo { // ... } @Table("BAR") class Foo { // ... } でも実際、Eclipseのコード書くのは大変です。
- 27. 困難なこと
- 28. 保存形式互換の維持 • 新機能追加したい • XMLの保存形式を変えると前のデータ が死ぬ • Jiemamyデータ構造の進化的設計orz
- 30. マルチDB対応 • RDBMSの種類は多い • MySQL, PostgreSQL, H2, Oracle... • そして各々のSQL文法がフリーダム過ぎ
- 31. 自動変更追尾 • 破壊的変更時… • データアクセスコードを変更 • データ移行 1:1 → 1:多 nullable → NOT NULL テーブル分割
- 32. 変更管理場所 • スナップショットのタイミング • VCS管理 v.s. データファイル内管理 （コミット v.s. ツール上での操作） • 逆方向の変更も自動化
- 34. ...コノヤロウ
- 36. 敗因: 不信と過信 • 静的型付けへの過信 • API利用者に対する不信 • APIの過度なフールプルーフ
- 37. 敗因: OOによる再利用の幻想 • データ保存形式(XML)の互換維持が重い • 拡張性のあるデータ形式 / API • オブジェクト指向の過信 • APIの過度な汎用化（外でも使おうとした） • 無駄に多くのコンポーネントに切り分け過ぎ た
- 39. Discussion