第三回DBリファクタリング

読書会都元ダイスケ

2012-08-30

自己紹介• 都元ダイスケ (@daisuke_m)

• Java屋です

• java-jaから来ま(ry

Javaオブジェクト指向Eclipse

恭ライセンス

薬

Mahout

Spring

XML JiemamyDDD

HadoopOSGi

Haskell

Scala

MavenWicket

AWS

酒

works

• @IT Database Expert 2008年9月

• 日経ソフトウエア

• Java入門記事

• Eclipse記事

• というOSSプロダクトを作っていま(す|した)

• 2006年頃から…。

• 軽い気持ちで始めたら、重いテーマだった。• 正直、欲張り過ぎて手どころか頭も回らなくなったプロダクトがこちらになります。

• 正直、本当に頭がまわらくなっているので、今日の話も多少混乱しますｗ

• この話をベースに、ディスカッションできれば有意義だよね、と思って話をします。

今日のポイント• Jiemamyで実現したいこと

• ひとまず実現できたこと実現できそうなこと

• 実現に際して大きな困難が伴うこと• Jiemamyが止まってしまったその他の理由

DBの進化的設計

Evolutional Database Design— Martin Fowler and Pramod Sadalage, 2003

http://www.objectclub.jp/community/XP-jp/xp_relate/evodb-jp

データベースリファクタリング

データベースリファクタリング

ごめんなさいなぜか

読んだ内容を全く覚えておりません

Evolutional DB Design

• 実装前に設計を確定させるのは、もはや不可能（→アジャイル）

• DBの設計に関しても同様で、リファクタリングを適用したい

• しかし、DBはアーキテクチャの低層に位置しているため、被依存度が高く、変更しづらい

• どーする？

not only refactoring

• DB変更はrefactoringだけではない

• テーブルやカラムの追加や削除

• 開発中のDBの変更履歴・構成管理

あらためてJiemamy

• DB構成情報を１つに集約 (smart model)

「重要なことはファイルを扱うようにデータベースを扱えるツールを持つことだ。」「スキーマとテストデータから成るデータベース」

• データファイルをVCS管理 (smart version control)

「マスターデータベースをソースコードと同様に構成管理の下に置くのである。」「全システムを管理する強力な構成管理ツールの下にあれば、もし最悪の事態が起こっても元に戻すのは難しいことではない。」

• ビルドフェーズでDB整備 (smart build)

「すべての開発者のデータベースに変更を自動的に適用する」

～ツール面からDBの進化的設計をサポート～

進化的設計Smart

VersionControl

SmartModel

SmartBuild

smart model• DBの構成情報を知っている唯一の存在

• この情報を元に、派生データを作る• DDL / テストデータDML

• DB設計書

• ER図

• データアクセスコード（エンティティ等）

database

tablecolumn

Java object SQL

Excel

class

smart version control

class Emp { String name; Busyo busyo;}

class Busyo { String name; // ...}

class Dept { String name; // ...}

class Emp { String name; Dept dept;}

smart version control

CREATE TABLE HOGE( ID integer ...);

@Table("HOGE")class Foo { // ...}

@Table("FOO")class Foo { // ...}

CREATE TABLE FOO( ID integer ...);

要は、チェンジセットを意識しなさいって話

smart build

• 一般的に、プロダクトをVCSからcoしてきてもすぐに動かせない

• DB環境の整備が必要

• ビルドフェーズでDB整備

• Mavenプラグイン

smart deploy?

• デプロイ時に、自動的にDB変更

• ServletContextListener

• ちょっと恐い → どうすればいい？

設計にあたって• データファイルはVCSにコミットしてdiff / mergeできるべき（バイナリ不可）

• データファイルからDB環境を自動構築できるべき

• スキーマだけではなく、テストデータも管理できるべき

• 多くのRDBMSで使えるべき

• 外部システムがこのデータを利用できるように、安定して使いやすいAPIを提供すべき

• DB変更内容を検知し、ALTER文等にマッピングできるべき

• データアクセスコードもリファクタリングに追従すべき

Jiemamy components

jiemamy-core

jiemamy-commonsapache commons

jiemamy eclipse plugin

maven-jiemamy-plugin

jiemamy-diagram

jiemamy-sql

DiagramEditorTableView

DbObjectEditPart

ExecuteMojo

JmDiagramJmNode / JmConnection

SqlStatementToken JmTable / JmView

JmColumnJmForeignKeyConstraint

SqlExecutor / UUIDProviderwoodstoxXMLInputFactory

XMLValidationSchema

UIApplication

Domain

Infrastructure

実現できたこと実現できそうなこと

diffとmergeが可能

• データ形式にXMLを採用

• きちんと整形し、diff / mergeに対応

• 手で編集する以上、補完も必要

XML Schema

API提供•Jiemamyモデルを自由に操作できる

database

tablecolumn

Javaコードから操作

Java object

SQL

diffモデル

• 2つのDB状態を compare/diff して、

DB変更モデルを作る

• 変更モデルがALTER文にマッピング

でも実際、diff のアルゴリズムは大変です。

リファクタリング自動化• テーブル名・カラム名を変更した時• テストデータのDMLも変更 → OK

• データアクセスコードを変更@Table("FOO")class Foo { // ...}

@Table("BAR")class Foo { // ...}

でも実際、Eclipseのコード書くのは大変です。

困難なこと

保存形式互換の維持• 新機能追加したい

• XMLの保存形式を変えると前のデータが死ぬ

• Jiemamyデータ構造の進化的設計orz

API互換性の維持

• 現段階であんまり気にすべきではない

マルチDB対応

• RDBMSの種類は多い

• MySQL, PostgreSQL, H2, Oracle...

• そして各々のSQL文法がフリーダム過ぎ

自動変更追尾

• 破壊的変更時…

• データアクセスコードを変更

• データ移行1:1 → 1:多

nullable → NOT NULL

テーブル分割

変更管理場所

• スナップショットのタイミング

• VCS管理 v.s. データファイル内管理

（コミット v.s. ツール上での操作）

• 逆方向の変更も自動化

diffとmergeの現実

• XMLの冗長性が高過ぎるからか、diffが上手く同期してくれない…

...コノヤロウ

Jiemamyが止まってしまったその他の理由

敗因: 不信と過信

• 静的型付けへの過信

• API利用者に対する不信

• APIの過度なフールプルーフ

敗因: OOによる再利用の幻想

• データ保存形式(XML)の互換維持が重い

• 拡張性のあるデータ形式 / API

• オブジェクト指向の過信• APIの過度な汎用化（外でも使おうとした）

• 無駄に多くのコンポーネントに切り分け過ぎた

敗因: Webとは違う

• DDDを適用した

• が、Repositoryパターンは無理ｗ

Discussion