Downloaded 13 times
20120830 DBリファクタリング読書会第三回
- 1.
- 2. 自己紹介 • 都元ダイスケ (@daisuke_m) •Java屋です • java-jaから来ま(ry Java オブジェクト指向 Eclipse 恭ライセンス 薬 Mahout Spring XML Jiemamy DDD HadoopOSGi Haskell Scala Maven Wicket AWS 酒
- 3. works • @IT DatabaseExpert 2008年9月 • 日経ソフトウエア • Java入門記事 • Eclipse記事
- 4. • というOSSプロダクトを作っていま(す|した) • 2006年頃から…。 •軽い気持ちで始めたら、重いテーマだった。 • 正直、欲張り過ぎて手どころか頭も回らな くなったプロダクトがこちらになります。
- 5.
- 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 データベース リファクタリング
- 8.
- 9. Evolutional DB Design •実装前に設計を確定させるのは、もは や不可能（→アジャイル） • DBの設計に関しても同様で、リファク タリングを適用したい • しかし、DBはアーキテクチャの低層に 位置しているため、被依存度が高く、 変更しづらい • どーする？
- 10. not only refactoring •DB変更はrefactoringだけではない • テーブルやカラムの追加や削除 • 開発中のDBの変更履歴・構成管理
- 11. あらためてJiemamy • DB構成情報を１つに集約 (smartmodel) 「重要なことはファイルを扱うようにデータベースを扱えるツールを持つことだ。」 「スキーマとテストデータから成るデータベース」 • データファイルをVCS管理 (smart version control) 「マスターデータベースをソースコードと同様に構成管理の下に置くのである。」 「全システムを管理する強力な構成管理ツールの下にあれば、もし最悪の事態が起こっても元に戻すのは難 しいことではない。」 • ビルドフェーズでDB整備 (smart build) 「すべての開発者のデータベースに変更を自動的に適用する」 ∼ツール面からDBの進化的設計をサポート∼
- 12.
- 13. smart model • DBの構成情報を知っている唯一の存在 •この情報を元に、派生データを作る • DDL / テストデータDML • DB設計書 • ER図 • データアクセスコード（エンティティ等）
- 14.
- 15. smart version control classEmp { String name; Busyo busyo; } class Busyo { String name; // ... } class Dept { String name; // ... } class Emp { String name; Dept dept; }
- 16. smart version control CREATETABLE 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 jiemamyeclipse 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
- 21.
- 22. diffとmergeが可能 • データ形式にXMLを採用 • きちんと整形し、diff/ mergeに対応 • 手で編集する以上、補完も必要
- 23.
- 24.
- 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
- 29.
- 30. マルチDB対応 • RDBMSの種類は多い • MySQL,PostgreSQL, H2, Oracle... • そして各々のSQL文法がフリーダム過ぎ
- 31. 自動変更追尾 • 破壊的変更時… • データアクセスコードを変更 •データ移行 1:1 → 1:多 nullable → NOT NULL テーブル分割
- 32. 変更管理場所 • スナップショットのタイミング • VCS管理v.s. データファイル内管理 （コミット v.s. ツール上での操作） • 逆方向の変更も自動化
- 33.
- 34.
- 35.
- 36. 敗因: 不信と過信 • 静的型付けへの過信 •API利用者に対する不信 • APIの過度なフールプルーフ
- 37. 敗因: OOによる再利用の幻想 • データ保存形式(XML)の互換維持が重い •拡張性のあるデータ形式 / API • オブジェクト指向の過信 • APIの過度な汎用化（外でも使おうとした） • 無駄に多くのコンポーネントに切り分け過ぎ た
- 38.
- 39.