Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20120830 DBリファクタリング読書会第三回

3,317 views

Published on

Published in: Technology
  • Be the first to comment

20120830 DBリファクタリング読書会第三回

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

×