20120830 DBリファクタリング読書会第三回
•
7 likes•3,371 views
Report
Share
Related slideshows
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