Database SmellsDatabase Smellsデータベースの不吉な臭いデータベースの不吉な臭い

奥野 幹也@nippondanjimikiya (dot) okuno (at) gmail (dot) com

＠データベース・リファクタリング読書会

免責事項

● 本プレゼンテーションにおいて示されている見解は、私自身の見解であって、オラクル・コーポレーションの見解を必ずしも反映したものではありません。ご了承ください。

自己紹介

● 今日は個人として来ています。– http://nippondanji.blogspot.com/– Twitter: @nippondanji

● MySQL サポートエンジニア– 2000 年にサン・マイクロシステムズ入社– 2007 年に MySQL KK へ転職– 気付くとまたサン・マイクロシステムズに・・・– 現在は日本オラクルに在席。– サポート一筋 12 年

● 日々のしごと– MySQL トラブルシューティング全般– Q&A 回答

など

私の日々の仕事はサポートです。

困ったことがなければ特に必要ない

しかし世の中そんなに甘くない

トラブルは日常！！

難問のラストリゾート・・・それがサポート！！

サポートの日常

● そもそも既に困っているからサポートへ– お客様が既に臭いに気づき・・・– 手に負えないからサポートへ！！– 既に手遅れな場合も

● よくあるパターン– 個性的なテーブルを目にすること幾多– ややこしいクエリ– 膨大なスロークエリログ

世界は不吉な臭いで充満している！

世界は不吉な臭いで充満している！！

● 全員が気づいていないことは誰も気付けない– ベストでないプラクティスが慣習に– みんなそれが普通だと思っている

● 日本的なるもの– 盲目的な前例主義– 変更を許さない官僚主義– 面子

● 間違いを指摘できない● 指摘しても聴く耳を持たれない

うまい空気を吸いたいです・・・

腐海に入ってはならん・・・

by ババ様

システム移行案件にて・・・スキーマは既存システムのものを

そのまま使います！！

作りなおす意味あんのかよ・・・

ロジックの実装はすべて PL/SQLなぜならアーキがそう決めたからです！

処理の大半はデータの整合性チェックだったり。それって DB の制約でできるよね？

お見積もりはテーブルひとつにつき○○万円です。→じゃあテーブル数を減らそう！

http://sec.ipa.go.jp/std/ent01-c.html

テーブル数が減れば良いってもんじゃ・・・

悲劇を避けるために

ほとんどの問題はテーブル設計に帰着する

● ひと言で言うと、リレーショナルモデルを無視した設計になっている場合は悲劇につながる。

– リレーショナルモデルを正しく使おう！！● 知らない場合はまず勉強しよう！！

– リレーショナルモデルを知らずに RDBMS を使うのは、オブジェクト指向を知らずに Java を書くようなもの。HTMLを知らずにウェブプログラムを書くようなもの。運転の仕方を知らずにクルマを走らせるようなもの。超危険！！

● リレーショナルモデル– リレーションの演算– 集合論理

● データベース設計理論– 正規化– 直交性

アンチパターンのストーリー

Press Enter■http://el.jibun.atmarkit.co.jp/pressenter/all_entrylist.html

第 1 回より引用

誰かが Java を教えている。地声なのか熱くなっているのか、講師の声はやたらと大きく、いつもより研修内容がよく聞こえていた。

　唐突に、その言葉が響いた。

　「オブジェクト指向など実業務では使い物にならない！」

　私は思わず手を止めてしまい、壁を見つめた。

〜中略〜

「オブジェクト指向の本とかサイトとか見ると、さぞすごいもののように書かれているけど、ないからないから、そんなこと。 20 年選手のオレが言うんだから間違いない！」

くれぐれも・・・

リレーショナルモデルなんて実践では役に立たないなどと

思わないでください。

RDBMS の落とし穴

● リレーショナルモデルに従わなくても強力だったりする– データに永続性がある– データをメモリ上にキャッシュできる– トランザクションがある– SQL によって柔軟な検索がおこなえる– インデックスにより高速な検索がおこなえる– バックアップやレプリケーションなどのツールが充実– 超便利！！

● 単なるデータの入れ物として使っていませんか？

リレーショナルモデルの利点

● 開発・メンテの効率化– Java に例えると・・・

● 例）オブジェクト指向を知らなくても Java は便利だが・・・– 豊富な APIやパッケージ– 強力な開発環境

etc● 待ち受けてるのは地獄

– 読みづらい、コードの重複がたくさん、バグだらけ– リレーショナルモデルに従うと

● アプリのコード量が減る● データの整合性をデータベースで保証できる● SELECT がストレートに● パフォーマンスの向上● データベースの変更が容易に

というわけでひっそりと連載しています

http://gihyo.jp/magazine/wdpress/archive/2012/vol69

次回は正規化のお話です。

まとめ！

世界は不吉な臭いが充満している！

● 感覚が麻痺しているかも– 内輪の常識を疑う– 赤信号、みんなで渡れば怖くない？

● みんな揃って地獄行き！！– プログラムや運用でカバーする羽目になる

● コスト大！！● 目を覚まそう！！

– 改善した結果どうなるか– 挫けず勇気をもって改善を。

危険を回避するために

● リレーショナルモデルに従う。– データベースの設計には必須の知識！！

● しかしまともに学習する機会はほとんどないかも。● 何はともあれリレーショナルモデルについての正しい理解

を。– RDBMS の基本機能だけで満足しない。– 正規化とはひと言でいうと重複を排除する作業

● 正規化していないとひとつの意味のレコードが複数の場所に出現してしまう

● すべてを同時に更新しないと更新異常に！！● データベースをリファクタリングしよう！！

– 世の中は危険な臭いで充満している！！– 勇気を持って改善を。

腐海に踏み込んだあなたへ。

● ガスマスクをつけよう。– 適切な防御で身を守ります。– 無ければ即死？

● 毒ガスの正体を見極める。– 多くのコードはデータの整合性確認に費やされる– 逆に言うと・・・

● 整合性確認漏れに注意が必要● 整合性は更新処理で問題になる

– 例）テンポラリテーブルを活用● 条件が複雑な場合にはスパゲティになりがち● ひとつの SELECT で解決するのではなく、短いクエリに区切る

● ストアドプロシージャのほうが上手に書ける場合も

お勧め書籍

● データベース・リファクタリング以外にも– SQL and Relational Theory– The Art of SQL– SQL Antipatterns– 44のアンチパターンに学ぶDB システム

ご静聴ありがとうございました。