SQLアンチパターンを読んだ(といいつつスライドだけ)

O'Reilly Japan - SQLアンチパターン http://www.oreilly.co.jp/books/9784873115894/

本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。
リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗(アンチパターン)があります。
本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、
それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。
複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、
MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。
日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。

とのこと。

アンチパターン一覧

ジェイウォーク(信号無視)
ナイーブツリー(素朴な木)
IDリクワイアド(とりあえずID)
キーレスエントリ(外部キー嫌い)
EAV(エンティティ・アトリビュート・バリュー)
ポリモーフィック関連
マルチカラムアトリビュート(複数列属性)
メタデータトリブル(メタデータ大増殖)
ラウンディングエラー(丸め誤差)
サーティワンフレーバー(31のフレーバー)
ファントムファイル(幻のファイル)
インデックスショットガン(闇雲インデックス)
フィア・オブ・ジ・アンノウン(恐怖のunknown)
アンビギュアスグループ(曖昧なグループ)
ランダムセレクション
プアマンズ・サーチエンジン(貧者のサーチエンジン)
スパゲッティクエリ
インプリシットカラム(暗黙の列)
リーダブルパスワード(読み取り可能パスワード)
SQLインジェクション
シュードキー・ニートフリーク(疑似キー潔癖症)
シー・ノー・エビル(臭いものに蓋)
ディプロマティック・イミュニティ(外交特権)
マジックビーンズ(魔法の豆)
砂の城

SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版) http://www.slideshare.net/t_wada/sql-antipatterns-digest

私はこちらのスライドで十分な満足感が得られました。

以下は感想

  • ジェイウォークってきれいな指してたんだねのTHE JAYWALKかと思ってたら、本当に信号無視って意味なんですね。安易にカンマ区切りでデータ格納しちゃうのはNGですね。
  • ナイーブツリーの閉包テーブルは今度試してみたい。
  • IDリクワイアドはわかってて使ってればOKってことで理解しました。
  • マルチカラムアトリビュートは横持ちじゃなくて縦持ちにしましょうよとかそんな感じでやりとりしてたけど、今後はこのメタファで話せそうです。
  • メタデータトリブルはパーティショニングしろっていうのはいいっすね。(そういえばなんかの案件でみたな、tablename_201303とかってテーブル)
  • ラウンディングエラーってMySQLでも対応できるんだろうかとか思ってたらDECIMAL(5,2)とか定義出来ますね。
  • サーティワンフレーバーはCHECK制約使わないし、いつも子テーブルにわけるからから気にしなくて大丈夫っぽい。
  • ファントムファイルは、ファイルはBLOB型に格納する方向で検討してみませんか?という話なんですけど、使ったことないな。整合性、トランザクション、ロック、権限管理できるっていうのがメリットとのこと。検討してみよう。
  • インデックスショットガン、なんでもインデックスつければいいってものではないという話。複合インデックスとか滅多に機能しないのに更新時のコストがかかっちゃうっていう。
  • フィア・オブ・ジ・アンノウンは不用意にNULLに恐怖する必要はないという話、でもわたしは基本的にNOT NULL制約をつけるようにしています。
  • プアマンズ・サーチエンジンはLIKE検索をもっと高速な全文検索エンジンに置き換えましょうという話、mroonga試してみたい。
  • インプリシットカラムは自然とSELECT * を避けてるから問題なし。
  • シュードキー・ニートフリークは思い当たる節がありすぎたので今後は注意します。
  • ディプロマティック・イミュニティはActiveRecord使って、MySQLWorkbenchとかでERDとかテーブル定義書とか出したりできるのであんまり意識しなくて良さそう。
  • 砂の城はDB設計の検討項目に入れておくともれなくてよさそう。

アプリケーションで整合性をとるっていうスタンスだと、別のチームが新しく作る別のアプリケーション、手動変更などで簡単に整合性が崩れてしまいます。

データベースがないアプリケーションは少数派だし、ウワモノより寿命が長いので、アンチパターンを避けるのは重要ですね。

このSQLアンチパターンを見て思ったのは、こういったノウハウが自分の所属する組織に定着していると、コミュニケーションが簡略化されてラクだなと。

社内勉強会でスライド眺めながらディスカッションするとよさげ。