2013/5/11　DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン」に参加

2013/5/11(土)の13:00より、DevLOVE関西「SQL アンチパターン・レトロスペクティブ関西・リターン」が楽天さんのカフェテリアで実施するというのをたまたま4月末に発見し、思い切って参加してきました。

SQL アンチパターンの本はそれより前に購入していて、内容を読んでてこりゃほとんどが該当するやん、と感じていましたが、それ以上の発展がなかったので今回をきっかけにより知識を習熟させたかったのが動機です。

SQLアンチパターン

作者: Bill Karwin,和田卓人(監訳),和田省二(監訳),児島修
出版社/メーカー: オライリージャパン
発売日: 2013/01/26
メディア: 大型本
購入: 9人クリック: 698回
この商品を含むブログ (26件) を見る

この日は見事に雨。
まあ四つ橋線の肥後橋駅からはかなり近いので、それほど困りませんでした。

会場に到着すると、参加証とA4両面にアンチパターンと簡単な説明が記載されたものを頂きました。

正直、アンチパターンを完全に覚えておけば、たとえ忘れてもこの紙さえ見れば思い出せるような紙でした。

本編

この日は和田さんが2名（和田卓人さん、和田省二さん）。そう、親子でお越しでした。
これまたラッキー。

この日は、最初はスライドを使ってのレクチャー形式、その後はグループディスカッション形式という流れでした。

SQL アンチパターン - 開発者を待ち受ける25の落とし穴

スライドとSQL アンチパターンの内容を元に、和田卓人さんにレクチャーしていただきました。

１部　論理設計
　１．ジェイウォーク　（信号無視）
　２．ナイーブツリー　（素朴な木）
　３．IDリクワイアド　（とりあえずID）
　４．キーレスエントリ　（外部キー嫌い）
　５．EAV　（エンティティ・アトリビュート・バリュー）
　６．ポリモーフィック関連
　７．マルチカラムアトリビュート　（複数列属性）
　８．メタデータトリブル　（メタデータ大増幅）
２部　物理設計
　９．ラウンディングエラー　（丸め誤差）
　１０．サーティワンフレーバー　（３１のフレーバー）
　１１．ファントムファイル　（幻のファイル）
　１２．インデックスショットガン　（闇雲インデックス）
３部　クエリー
　１３．フィア・オブ・ジ・アンノウン　（恐怖のunknown）
　１４．アンビギュアスグループ　（曖昧なグループ）
　１５．ランダムセレクション
　１６．プアマンズ・サーチエンジン　（貧者のサーチエンジン）
　１７．スパゲティクエリ
　１８．インプリショットカラム　（暗黙の列）
４部　アプリケーション
　１９．リーダブルパスワード　（読み取り可能パスワード）
　２０．SQLインジェクション
　２１．シュードキー・ニートフレーク　（擬似キー潔癖症）
　２２．シー・ノー・エビル　（臭いものには蓋）
　２３．ディプロマティック・イミュニティ　（外交特権）
　２４．マジックビーンズ　（魔法の豆）
　２５．砂の城
 SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)

アンチパターンの内容はあらかじめ本を読んでいたので理解に困ることはありませんでしたが、内容を改めて認識することができました。
また印象に残ったこととして、アンチパターンの構成とネーミングがありました。

デザインパターンでもそうですが、「○○パターン」の命は名前。（しかもカタカナで）
インデックスショットガンなんて、印象に残りまくりです。
なので何かパターンを作るときは名前をしっかり考えないと周りに定着しない、そんなお話でした。

SQL アンチパターン・レトロスペクティブ

この時間は現場の経験談、失敗談を話し合い、各チームがそれを発表するという形式でした。

うちのチームでは一通り見てこれもあるよね、あれもあるよねという話になりましたが、その中でもキーレスエントリ（外部キー嫌い）で盛り上がりました。
理論的にある方がデータ構造が崩れないとはわかっているのですが、当初の設計思想から入ってなかったり、細かい業務フローの要求に答えていく中で外部キー参照が無くなる、など。

あと、テストをするときにわざわざ関係ないものでもそれを参照している全データを作る必要があり不便、という話も出ました。
今思えばそれは単に開発者がラクをしたいだけなのかもしれませんが。
ユニットテストで外部キー参照のテストをしないわけにはいかないでしょう、と少し時間がたった今、客観的に思うところがあります。

他のチームを含め、比較的アプリ寄りのアンチパターンがよく出ました。
自分は最近は基幹系ということだからか、もしくはたまたまそういうSQLが多いからかわかりませんが、論理設計のアンチパターンだけでもお腹がいっぱいです。
あとは物理設計のインデックスショットガンでしょうか。
最近はショットガンが逆になさすぎて悩まされることが多いですが。。（要はインデックスがデータ量の割にあまり張られていない）

26個目の落とし穴を探せ

今回のSQL アンチパターンには25個のパターンが記載されていましたが、では26個目を各チーム議論して出してみましょうという時間でした。
自分のチームは3名の構成だったのですが、自分自身講義の中で1つのアンチパターンを思い浮かべてたのでそれを説明しました。

アンチパターン名は「Deadbeat Datetime (時間に疲弊)」
テーブル定義での日付型とアプリケーションでの日付処理に悩んだことはないでしょうか。
　・DATE型で定義したのに時分秒がシステム導入当初は入っていたが、途中の改修より入らなくなった
　・誕生日のカラムはDATE型？varchar(8)？varchar(10)？varchar(6)？number(8)？number(20)？timestamp型？
　・between等での日付の検索を考慮してる？
　・手動更新する場合はしっかりルール決めしている？

個人的に非常によく悩む問題だったのでとりあげさせてもらいました。
＃納得してもらえたかな〜(´Д｀)

その他にも「メタデータトランスフォーマー」や「とりあえずDB」といったユニークなアンチパターンが次々と発表され、ふむふむとうなずく時間でした。