IBM主導のDB2の勉強会であるClubDB2に参加して参りました。
今回は、ミックさんによる「達人が語る こんなデータベース設計はヤダ！」でした。
↓資料はこちら
http://d.hatena.ne.jp/mickmack/20120714/1342246442
↓議事メモはこちら
https://docs.google.com/document/d/1b009Pr7bpDT0lyDD8kzDd5Hs_XYfXbMRuj6LUhCiONA/edit
印象的だったお話は3つ。
- ループを利用したSQLの連続使用は禁止
これは、手続型言語を利用している人に多くみられるもので、whileやfor文の間にSQLを入れて小さいSQLを何度も発行してしまうような処理です。
このようなプログラムは本来1回のSQLで複数の行や列でとってくるのが正しいやり方です。
もし、ループ利用したSQLを発行してしまうと1回のSQLは頑張っても0.01～0.1msです。複雑なSQLな場合1ms程度。しかし、ループを使ってしまうことで、100ループしただけで、複雑なSQLよりも遅くなってしまうことがわかります。
皆さんも注意しましょう。 - 論理設計は限りなく美し、そして物理で対応しよう。
これは言葉のままです。パフォーマンスを向上させるためには、論理設計、物理設計の両方で対応することができますが、可能な限り物理で対応(メモリの増設など)した方が良いというものでした。
その方が、保守もしやすく、チューニングのために時間をかける必要もないため、結果的に安く済むそうです。
たしかにそうですね。中小企業では微妙ですが。 - ディスクorストレージに触ってはいけない。
DBは可能な限りメモリで処理を完結しましょう。当たり前の話ですが、意外に難しいですね。メモリも安くなったので足りなくなったら足せばよいという話でもありますが・・・
今回の話のポイントは、ディスクはこれ以上進化しない。そのため、メモリで処理しないといけない。SSDもメモリっちゃメモリですからね。
また、DBサーバーではストレージを利用していることが多いですが、ストレージの設計やチューニング、見積もりの方法が世の中であまり公開されていなく、非常に困難であるということ。
また、ライトニングトークでは、jfluteさんによるDBfluteの概略説明でした。
DBfluteって初めて聞いたのですが、簡単に説明するとOSSのO/Rマッパだそうです。
DB設計者の視点から作ってあるため、上で説明したループ利用した処理も利用していないとのことでした。
対応言語は、JavaとC#だそうです。
