データベースリファクタリングについて話をしてきた #OSO2017

岡山にはオープンセミナー岡山と言う最高のイベントがあります。

okayama.open-seminar.org

昨日は id:t-wada さんや id:naoya さんの資料がホットエントリー入りしてました。
この登壇はそれと同じイベントになります。
その他の方も超豪華講師陣の中で、私が出来る精一杯の経験も踏まえたお話をさせていただきました。

speakerdeck.com

この中で出て来る、データベースリファクタリングは本当に素晴らしい本です。
OracleベースなのですがMySQLだろうがPostgreSQLだろうが必ずためになる本です。
ですが、この本は既に廃刊になっており再販の予定もありません…
僕は後世に絶対必要な本の一つだと思っているので再販のためにも皆さんの要望の声を上げていただけるとうれしいです。
そしたらもしかしたら本が世に復活するかもしれません。

またSQLアンチパターンもご紹介しましたがこちらは絶賛販売中なので是非読んでください！！
最高です。

まだ読んだこと無い人は是非読んで下さい。

伝えたいこと

オープンセミナー岡山は最高のイベントなのは周知の事実なのでその件についてはまた別途まとめようと思います。
このエントリーでは資料には書いてないけど大切な事を伝えておきます。

結論、データベースリファクタリングは停止を伴うことも多々ありますし、複数のアプリケーションから1つのDBを参照していることも多々あるので政治的にも技術的にも影響範囲が広いです。
そこを乗り越えるためには入念な準備と適切な判断が必要です。
だから事前準備として

• テストとモニタリングで変更前と変更後を正しく比較できること
• 改善に対するチームの課題を共有すること
• そのリファクタリングは本当に必要か本質を捉える事

なんかが大切になります。

本質について言えば「この設計は非正規されてる！直すんだっ！！！」と思ってもよく調べれば、JOINのコストを下げるための苦肉の策だったかもしれません。
またはMySQLで外部キー制約によるデッドロック回避だったかもしれません。
どちらも苦肉の策なのは間違いありませんが「兎にも角にも直すんだ！」とすると本質を見失います。
もちろん影響範囲が高いため、改修コストがメリット無いと判断されることもあると思います。
しかし糞なDBの上にどんなアプリケーションを組んでもクソという言葉もあるとおり、DBの設計はアプリケーション、サービス共に大きく影響を与えるのも事実です。
だからこそ、DBの変更には時間もコストも掛かるからこそ、定期的に小さく改善し続けることが長くデータを活かすコツだと思っています。
みなさんもこのエントリーを見て思うところがあれば、これを機に今日からデータベースリファクタリングを初めてみてください！