makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「DBリファクタリング読書会 第二回」に参加しました

2012/7/10(火) 「DBリファクタリング読書会 第二回」に参加してきました。

ATND
http://atnd.org/events/30394

Ustream
http://www.ustream.tv/recorded/23893625


データベース・リファクタリングデータベース・リファクタリング
(2008/03/26)
スコット W アンブラー、ピラモド・サダラージ 他

商品詳細を見る



第1回に引き続き、会場は日本オラクル青山センターです。私の会社からだと40分ほどで着きました。
スタッフの方々も含めると、20人弱くらいいたのかな。

データベースって、ソフトウェアエンジニアには避けられないテーマですよね。。。
データベースを使用しないシステムなんてありえないですから。
酷い設計のDBを目にしたことのあるエンジニアさんも多いのではないでしょうか。
私も、???な構造のテーブルを何回も目にしたことがあります。

そんなDBを時々目にしつつも、私がデータベース設計について更に大きく意識するようになったのは、
IPA情報処理技術者試験の「データベーススペシャリスト」を取得したときでした。
試験問題が、徹底的に正規化を意識させるDB設計を求める出題になってて、
あの勉強をすると嫌でも相当鍛えられると思います。。。

あと、ウチの会社もHiRDBってDBMS製品を作ってるので、なおさらDBMSを意識する機会は多いです。
ちなみに、日経コンピュータのパートナー満足度調査で、2012年度はHiRDBが1位だったようです。
でも、OracleやSQL Serverよりユーザ数少ないし、1位って言ってもなぁ。。。


そんなこんなの私にとって、この勉強会は非常に興味深いものでした。

さて、勉強会のTOPは @nippondanji さんによる講演「データベースの不吉な臭い」です。

Database smells
View more presentations from Mikiya Okuno


MySQLのサポートエンジニアを長年担当されているとのことで、データベースに対する深い知見に基づいた、
とても興味深い内容でした。私の心に響いたフレーズをいくつか以下に挙げてみます。



■ほとんどの問題はテーブル設計に帰着する。リレーショナルモデルの知識は必須!

■リレーショナルモデルの利点
 ・アプリのコード量が減る
 ・データの整合性をデータベースで保証できる
 ・SELECTがストレートに
 ・パフォーマンスの向上
 ・データベースの変更が容易に

■DBの正規化をしないと、多くのコードはデータの整合性確認に費やされるハメになる。

■勇気を持ってデータベースをリファクタリングすべし。




でも、一番印象に残ってるのは、スライドに書かれた大ババさまの一言でした。。。
ナウシカ、私も大ファンなんです。原作7巻セット、いまも大事に持ってます!


@nippondanji さんの講演後は、参加者さんと主催者さんがイスを寄せ合っての座談会です。
参加者みんなでポストイットに議論したい内容を書いて、そこからいくつかピックアップして
みんなで議論を進めていく進行方法でした。

この方法、かなり良いですねー。議論や意見交換が活発に行われて、とても有意義でした。
20120710_dbrr.jpg

トリガーやストアドプロシージャの使いどころや応用方法、区分値テーブルの扱い、
外部キーの参照設定を貼るべきか否か、正規化と性能のバランス、などなど、非常に興味深い
テーマについて深く意見交換できました。

特に私にとっては、トリガーやストアドは使ったことなかったので、他のエンジニアさんの
経験や使いどころの話を聞くことができたのが凄くためになりました。

覚書として、議論した内容をいくつか羅列してみます。

■トリガーが多すぎると、そもそもDBの設計がマズいことを意識すべし。(カラム重複が多い可能性大)

■トリガーで監査証跡用のログを出す運用をしているが、更新処理とトリガーからのログ出力は
 別トランザクションにしないと、ロールバック情報が監査証跡として残せなくなるので注意すべし。

■ストアドはDBMSの種類によって変わるので、使いすぎると移植性や保守性を落とす。

■ストアドを使うと、APサーバやバッチサーバではなく、DBサーバに負荷がかかることになる。

■ネットワークの負荷を減らしたいなら、ストアドも有効な選択肢となる。

■参照ONLYのテーブルならば、あえて正規化せず性能重視にすることもありえる。

■外部キーを設定すると性能が落ちるというのは都市伝説である!

■外部キーを設定することで、クエリの発行回数を減らせる。

■外部キーを設定しないと、親テーブルにデータがあるかどうかをアプリ側でSELECT発行する必要がある。

■巨大な区分値テーブル1つで様々なコードを扱っているようなマズい設計は、Oracleだと
 パーティションテーブルを使うことで解決できるかもしれない。





途中から懇親会のピザも届いて、ビール飲んでピザ食べながらの座談会になりましたw
座談会の議論も白熱して、ふつーに懇親会の時間になっても議論が継続してましたね。
やっぱ、みんなデータベースに興味あるんだなぁ、と思うひとときでした。


懇親会の最後に未開封のワインが残ったので、持ち帰り用にじゃんけん大会になりました。
んで、なんと2本目のワインのじゃんけんで、一発勝ち抜き!白ワインげっとしましたー
思わぬお土産もゲットして、お酒好きな私としては大満足です。


とても有意義な時間をすごせて、参加してホント良かったなぁと思います。
次回もぜひ参加したいです。
ただ、個人的な要望ですが、第2火曜日は避けてもらえると嬉しいかも。。。
別件の勉強会と重なってしまうので。次は月曜日とかがいいなぁ

最後に、会場を提供してくださったOracleの@yokatsukiさんはじめ関係者様、スムーズに運営してくださった
@akitsukadaさんはじめ主催者の皆様、ありがとうございました。次回も楽しみにしてます!

あ、あとツイートをtogetterで纏めました。


スポンサーサイト

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。