Atnd（告知ページ）
http://atnd.org/events/31517
以下の書籍をターゲットとした読書会なのです。
 | データベース・リファクタリング (2008/03/26) スコット W アンブラー、ピラモド・サダラージ 他 商品詳細を見る |
ただ読書会といっても、みんなで集まって本を読むのがメインではなく、DBリファクタリングに関する発表や座談会が中心です。私は第１回から参加してますが、今日が第３回の開催でした。
会場は日本オラクル青山センターです。
３回目の参加なのに今日初めて知ったんですが、オラクルの真ん前に神宮球場あったんですね。。。
ちょうどヤクルト戦が開催されてて、ラッキー７のイニング合間だったのかどうかよくわかりませんが、球場の近くから花火が盛大に上がってて、それをみんなでオラクル13Fから眺めてました。
あと当日の様子のブログは、他の方が既に数名、詳細に書いてくださっていますので、そちらが参考になるかと思います。
私も自分への覚書として、当日とったメモを元に、感じたことを思いつくまま書いてみようと思います。
自分なりに後で纏めてみる事、情報の整理や知識の定着の観点から、きっと大事。
開会の挨拶 （ @do_aki さん）
「PHP Apocalypse」というイベントが、この読書会を始めるキッカケだったそうです。
ググってみたら、Atndの告知サイトとか見つかりました。なるほど、こんなイベントだったんですねー
実際に読書会を立ち上げた行動力は、ともて素晴らしいです。おかげで今日の読書会に参加できるわけだし！
スポンサーセッション （ @yokatsuki さん）
いつも素晴らしい環境を提供してくださる@yokatsukiさんからのご挨拶です。以下メモ。
■Oracleで研修講師を担当されているとのこと。
■研修を受講する人は、一部の限られた人である。またOracle製品ありき、で受講しに来る。
■そういうのではなく、もっとオープンに技術力を育成する機会が作れないか？と考えた。
■アイデアとして、せっかく自分がOracleに所属しているのだから、その特典としてOracleのフロアを使用することを考えた。
■技術力を高める活動に今後もかかわっていきたい。
■良いアプリを使って良いサービスを提供していく取り組みに参加していきたい。
---
素晴らしいですね。いつもマジ感謝です！
講演 （ @daisuke_m さん）
@daisuke_mさんがOSSとして開発しているデータベース設計・リファクタリングサポートツール「Jiemamy」の講演です。
ちなみに私、入社以来かれこれ「日経ソフトウェア」という雑誌を8年くらい定期購読してて、毎号読んでます。んで、@daisuke_mさんの連載や記事が、日経ソフトウェアによく掲載されているんですよねー。かなり読みやすい内容に纏まっていて、いつも読んでました。
以下、講演のメモです。
---
■「データベースの進化的設計」に関する記事を2008/9に@ITに書いたとのこと。（ググってみると、↓がヒットしました）
Jiemamy作者が考える “データベースの進化的設計” データベースもアジャイル開発に対応したい！
■データベースの進化的設計
ちなみに、↑に出てきた「データベースの進化的設計」ですが、原文は英語です。
なお今日の出席者でもある @t_wada さんが日本語に訳されています。コチラ
（ ちなみに、この読書会の初回の講演者は @t_wada さんでした。そこでもお話ありましたね）
■「データベースの進化的設計」をサポートするツール、Jiemamy（じーまみー）をOSSとして開発していた。
（ただ、対象範囲を広げすぎて回らなくなったそうです。１年くらい何もしてない状況とのこと）
■Jiemamyの設計思想
(1) Smart Model ： DB構成情報を１つに集約する。
(2) Smart Version Control ： データファイルをVCS(Version Control System）で管理する。
(3) Smart Build ： ビルドフェーズでDBを整備する。
以下、詳細に見ていく。
■(1) Smart Model
① DBの構成情報を知っている唯一の存在を作る。
② この情報を元に、DDLとかを自動生成する。
■(2) Smart Version Control
① 開発現場では、ソースはSubversionとかで管理しているのに、SQLはなぜかファイルサーバとかで管理されてることが多い。。。
② SQLとか、他の定義情報もバージョン管理する必要がある。
■(3) Smart build
① Mavenプラグイン
■(4) Smart deploy （現在考えている、やってみたいこと）
① デプロイ時に、自動的にDBを変更する。（alter table文の発行）
② ちょっと怖い。。。どうすれば良いか。。。
■Jiemamyの設計にあたって
① データファイルはVCSにコミットして、diff/mergeできるべき
② データファイルからDB環境を自動で構築できるべき
③ スキーマだけでなくテストデータも管理できるべき
④ 多くのRDBMSで使えるべき
⑤ 外部システムからJiemamyを使えるAPIを提供すべき
⑥ DB変更内容を検知してAlter文などにマッピングできるべき
⑦ データアクセスコードもリファクタリングに追従すべき
■↑で実現できたこと／できてないこと
① データファイルはVCSにコミットして、diff/mergeできるべき
→ できた。diff比較するにはバイナリ不可。XMLにして、EclipseでもXMLタグ補完できるようにしたい。
⑤ 外部システムからJiemamyを使えるAPIを提供すべき
→ できた。
⑦ データアクセスコードもリファクタリングに追従すべき
→ 実現できそうで手が届かない。２つのDB状態をcompare/diffするアルゴリズムが大変そう。
→ DB変更モデルを作るのが、できそうでできてない。
■困難なこと
① 保存形式互換の維持
バージョンアップでXMLの保存形式を変えると、前のバージョンのデータが死ぬ。。。
② マルチDB対応
ムズい。。。各々のDBMSのSQL文法がフリーダム過ぎ。NUMBER型とか、何だよ！
③ 自動変換追尾
テーブル分割などの破壊的変更時に対応できない。。。
④ 変更管理場所
DBのスナップショットを取るタイミングが難しい。。。
どの状態がコミットされた状態なのか、判断が難しい。
■Jiemamyの開発が止まった理由
① 静的型付きへの追従
→ エラーはコンパイル時に全部発見してやろう、みたいな。。。
② OO（Object Oriented: オブジェクト指向）による再利用の幻想
③ クライアントアプリはWebアプリとは違う
→ ドメイン駆動設計（DDD）を適用した。が、Repositoryパターンは無理。。。
休憩時間中のLT （ @hayamiz さん）
■データベースの歴史を記した本を作って、コミケで売ってみた。１時間半で70部が完売した。
The Database Times vol.1
■今日の読書会でも10部を販売 → 完売！
■東京大学の博士課程で、DBについて研究しているとのこと。（すげー）
---
こーいうネタでコミケに参加するという発想は斬新で、驚くと共にマジ関心しました。
いやー、コミケという場でも、こういうOutputの手段があったのかー。。。
座談会
座談会でネタにしたい内容を各自がポストイットに書き込み、ホワイトボードに貼りました。こっからスタートです。
■DBAってPJに存在しているか？
→ アプリ開発する人がDB触っちゃうことが多い。
→ 大きいPJだと、基盤チームとかがあって、そこがDBを管理することが多い。（ウチの会社のPJも、大半がそう）
■早く止めるアプリやサービスに、DBリファクタリングは必要ない。
■アメー○ピグは、MongoDBを使っているらしい。
■「不吉な臭い」（前回の2章ネタでもある）があったとしても、DBのリファクタリングを始めるかは別の話。
■システム障害が発生してDBをリファクタリングした経験がある参加者さんがいらっしゃった。
(1) 障害背景
NOT NULL制約を付けておくべきカラムにNULLを許した設計にしてしまい、インデックスが効かずに性能劣化。。。
(2) テストはというと。。。
テスト段階ではデータ件数が少なかったので、性能問題は顕著化しなかった。（いわゆる潜在バグの状態）
■迅速な経営判断を可能にするために必要な情報を整備する必要があり、経営層がトップダウンでDBリファクタリングを推進した事例がある。（ただしこのような事例は稀）
■DBMSのMは、ManagementのM。本来、DBの管理情報はDBMS自身が保持し、DBMS自体がDB構造をManagementできるべき。
→ Jiemamyが第三者としてDBMSの管理情報を持つ時点で、DRY（Don't Repeat Yourself）の原則が崩れているのでは？
→ SQLの海面下で各DBMSが管理しなければならない現状がある。
→ DBMS自体にスキーマのログを持たせることも可能。
ただ、DB自身が保持している情報にアクセスするインタフェースが無い。
■DBの構成情報を見たからといって、DBを前の時点に戻せるとは限らない。
→ 例えばOracleにはフラッシュバック・データベースという機能があり、時間の単位でDBを元に戻せる。
ただし、その時点から発生したデータは消えてしまう。
（cf. フラッシュバック・データベース： http://www.oracle.co.jp/2shin/ora79/16_17.html）
■本質は、スキーマとデータは密接に関連している。分けるべきではないのでは？
■テーブルを統合した後、分離して戻そうとした時に、データを元どおりに分けられずハマった。
→ データレベルで見分けがつくようにしておくことが大切。
■リファクタリングでは、「いつでも元に戻せる」ことが重要。少しずつリファクタリングする。
ただ、「開発効率」と「実行効率」は違う点に注意が必要。
(1) 開発効率：
開発では少しずつリファクタリングして進めるべし。（Small Step）
そうしないと何してるかわからなくなって、死ぬ。。。
(2) 実行効率：
少しずつリファクタリング、では時間がかかる。
プロダクションに細かくマイグレーションするのは、実際は難しい。
プロダクションへ適用前にマイグレーションをsquash（※）すると良い。
（※）
squashという単語、恥ずかしながら今回始めて聞きました。ちょと調べた限りではGit用語のようで、
「ブランチの修正した内容すべての変更を取り込む」ことをするときに使うようです。
(いつもはSubversion使ってるので、Gitはgit cloneくらいしか使ったこと無い。。。）
■データベースリファクタリングの移行期間は、ビュー（View）を緩衝材として使うことで解決することが多い。
・参照系テーブルなら大体いける。
・更新系テーブルだと、難しい。。。
■本番と同じサンドボックス環境を持っているPJって、これまでありましたか？
→ 誰もいない。。。
→ 最近ではクラウド環境を用意することで、ハードを購入せずとも本番と同じサンドボックス環境を
一時的に持つことは可能になった。（金で解決できる時代になった）
■データベースリファクタリングの移行期間に、開発が終了したようなほとんど使われていないアプリから、移行前のテーブルにアクセスしてくることがないかを見極める必要がある。
→ DBリファクタリングでは、メンテされてないアプリやDBの存在が問題となる。
そもそもメンテされてない場合は管理者がおらず、話す相手がいないので調整さえできない。。。
■Oracleの場合、データベースを統合するとライセンスが安くなる。これがDBリファクタリングのキッカケになることもある。
懇親会
同じ場所で、引き続き懇親会です。
とはいっても、今日は読書会開始の最初からピザとビールが来て飲み食いしながらの進行でしたので、改めて懇親会が最後にあったというよりも、座談会に引き続き参加者さんと交流する時間が取られたイメージでした。
私も数名の方々とお話させていただいたのですが、@t_wadaさんと@daisuke_mさんと直接会話する時間が持てなかったのが少し残念でした。（恐れ多かった、というのもある。。。）次回以降にとっとこう。
今回も大変有意義な時間を過ごすことができました。
主催者様、運営者様、会場提供様、発表者様、皆様いつもありがとうございます。
次回も楽しみにしてます。
以下、ツイート一覧です。
