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

2,542 views
2,456 views

Published on

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,542
On SlideShare
0
From Embeds
0
Number of Embeds
470
Actions
Shares
0
Downloads
11
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

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

×