Source: flickr.com via garage-kid on Pinterest
に引き続き、第三回にも参加してきました。購入してみたはいいものの積読になっていた本書を読むとてもいい機会だと活用させてもらっています。
現状、わたしは少しづつ読み進めていて、今は「第六章 構造リファクタリング」が読み終わったところにいます。
第三回目の本読書会は、「第三章 データベース・リファクタリングのプロセス」をメイントピックとして行われました。
では、以降、わたしがとってきたメモのシェアになります。
Contents.
ゆるゆる開会 @do_aki さん
▶ きっかけ
- php apocalipse
▶ 今回のDBRRは？
- Jiemamy の @daisuke_m さん
- いつものとおりゆるふわで
▶ 謝辞
スポンサーセッション @yokatsuki さん
- 研修講師
- Oracle University
- 研修にこれる人は限定されている人
- Oracle製品ありきできている人
- 世の中にはたくさんのエンジニア、学びの場を提供
- 技術力をたかめよう
- そのとき、自分ができることを考えた
- Oracle のこの場を提供しよう
- DBRR は願ったり叶ったり、DBの話だから
- DBに限定はしない
- 最近の関心はアプリケーションをつくるということにあるのではないか
- もし勉強会をやりたいけど場所に困っているなどあれば、ご相談ください、とのこと。
＊
- 床に電源、自由に使ってよい。
講演： Jiemamy の @daisuke_m さん
Home - Jiemamy Project - これは単なるER図エディタではない！ 画期的なプロセス改善プロジェクトである。
▶ 自己紹介
- Java屋さん
- Eclipse、Javaとか大好き
▶ Works
- 日経ソフトウェアなどでJavaの入門記事など
▶ Jiemamy
- というOSSをつくっていました
- 2006くらいから
- 直近、1年くらい何もやっていない
- 重いテーマ
- 正直、本当に頭がまわらなくなっている
▶ 今日のポイント
- Jiemamyで実現したかったこと
- 開発がとまってしまった理由
▶ DBの進化的設計、DBリファクタリング
- 論文がある
- DBリファクタリングの源流にあるような論文
- DBの進化的設計、論文を翻訳した方→和田さん
▶ Evolutional db design
- 実装前に設計を確定させるのはもはや不可能
- しかし、基盤にあるためDBリファクタリングはむずかしい
- ではどうする？
▶ not only refactoring
- DB 変更だけがリファクタリングではない
▶ Jiemamy
- ツールからリファクタリングできないかとはじめた
▶ 進化的設計
- smart model
- DB構成情報を1つに集約
- smart version control
- データファイルをVCS管理
- smart build
- ビルドフェーズでDB整備
- すべての開発者のDBに変更を自動的に適用する→Java屋の発想
▶ smart model
- DBの構成情報を知っている唯一の存在
- この情報をもとに、派生データをつくる
- DDL、DML
- DB設計書
- ER図 etc...
＊
- Jiemamy、表向きはER図の作成ツールのよう
▶ smart version control
- チェンジセットを意識しなさいという話
- SQLだけはファイルサーバーで管理されていたなどの経験から、これはポイントと考えた
▶ smart build
- Maven plugin
- 一般的に VCS から co してもすぐにうごかない
- DB環境の整備が必要
▶ smart deploy?
- deploy 時に自動的にDB変更
- ちょっとこわい→どうすればいい？
▶ 設計にあたって
- データファイルはVCSにコミットしてdiff/marge できるべき
- データファイルからDB環境を自動構築できるべき→Maven Pluginで実現
- スキーマだけでなくてテストデータも管理できるべき
- 多くのRDBMSでつかえるべき
- 外部システムが利用できるようにAPI
- DB変更内容を検知してAlter文にマッピングできるべき
- データアクセスコード
▶ Jiemamy component
- UI application
- jiemamy eclipse plugin, maven-jiemamy-plugin
- Domain
- Jiemamy-diagram, jiemamy-sql, jiemamy-cores
- Infra
- jiemamy-commons, woodstox, apace commons
▶ 実現できたこと
- diff/merge が可能→XMLを使用
＊
- API提供→Javaコードからアクセス
▶ 実現できなかったこと
- diff モデル →2つのDBを比較してDB変更モデルをつくる
＊
- リファクタリングの自動化
- テーブル、カラム名を変更した時、
- テストデータのDMLも変更するなど
＊
- 保存形式互換の維持
- XMLの保存形式を変更すると前のデータが死んでしまう
＊
- API互換性の維持
＊
- マルチDB対応
- MySQL、PostgreSQL、H2、Oracle
- 各々がフリーダムすぎる
＊
- 自動変更追尾
- 破壊的変更時
- データアクセスコードを変更、データ移行
- 自動化できるのか、そもそも
＊
- 変更管理場所
- スナップショットのタイミング（今は git に丸投げ）
- VCS管理 vs. データファイル内管理
- 逆方向の変更も自動化
＊
- diff/merge の現実
- XML コノヤロウ
▶ Jiemamyが止まってしまったその他の理由
- 敗因：不信と過信
＊
- ほげほげによる再利用の過信
＊
- ClientアプリはWebとは違う
The Database Times vol1. の宣伝。
- DBの昔話的なもの。
- 夏コミで販売。
- はやみずさん
- 東大博士2年
- バク速のDBエンジン
- メロンブックスさんでオンライン販売
座談会メモ
- 大規模とはなんぞ？
- →関係者の数
- →DBの依存度
- →テーブル数
- →レコード数
＊
- リファクタリングのきっかけってどんなものがありますか？
- トラブル → e.g. Not Nullでなければならないカラムがあった、indexが効かなかった
- よりよい機能を提供したいというモチベーションの結果（普通の開発プロセス、当たり前の活動）
- 機能追加
- 改修
- 経営者判断、トップダウンの指示（稀なケース）
＊
- Jimamy を作ろうと思ったきっかけは？
- DBのプロダクト管理をするものがころがってなかったから
▶ 構成管理
- smart model は無理
- DBMS の M はManagement の M
- DBMS の中で行われるならともかく、外部で行われると、そこをスルーして変更が行われると意味がないのでは？
- DBの更新ログの中に残ってるはず
- どう使いやすい形で表に出すかでは？
▶ 変更管理
- どの程度、ロールバックできるのか？
- 今動いているDBを変えるのは難しいんじゃ
- Oracleは、フラッシュバックデータベース機能はある
- あくまで、ある定時定点に戻せるというだけ
- （まあ、いきなりプロダクションのDBにリファクタリングする人はいない。サンドボックス→ステージ→プロダクション。アップとダウンのテスト。結合のマイグレーションはアップとダウンを見分けられない。変更に強い設計視点が必要）
▶ Versrsion 管理
▶ リファクタリング
- small step は効率悪そう
- とは言っても、いつでも元にもどせる状態を確保したながら進めることが必要なのではないか
- 着実に変更を進めるためにも必要なこと
- e.g. マイグレーションはsmallじゃないとなにしているか分からない。プロダクションには小さくマイグレーションできない。プロダクション手前にスカッシュ的なことをするとかで両立。
▶ 環境
- サンドボックスとステージ環境は違うということで合ってる。
＊
- ステージ環境の用意
- クラウドなら余裕（テストのときに増やして、終わったらなくす）→あくまで金で解決するアプローチ
- そういかない場合は？
- 想像するしかない→考えること
▶ チーム
- 移行期間はどうやってきめるのか？
- ビューを使って解決→変更したイメージを先に提示（参照系なら、ビューで解決できることは多い）
- DBは先に変えているとか。
- 新旧のDB構造をもってどちらにも更新するような仕組みとか。（DB側で用意する）
- ステージ環境で試験。
＊
- 開発終了したアプリ
- →移行期間で確認
