SQLアンチパターン・レトロスペクティブ関西に行ってきた
今日にいたるまで『SQLアンチパターン』についてブログを書こうとして、
２回失敗してます。
１回目：『SQLアンチパターン』を読んだ
最初はあまり期待していませんでした。
題名からしてなんとなくおもしろくなさそうだった。
そもそもオライリーだし、取っつきにくいはずだ。
（ここは正直に…）
ただ、好評なツイートが多かったので買ってみました。
2,3章読んで、考えが一転しました。
おもしろい。スラスラ読める。あまりのデジャブ感に笑える。
これはブログ書いてまとめようと思いましたが、そこ止まり…
２回目：デブサミで『SQLアンチパターン』にサインしてもらった
読んでる時にちょうどデブサミに参加することができて、
もしかしてと思ったら監訳者の和田さんのサイン会がありました。
「ブログとかで感想ください」
和田さんにそう言われたので、ネタもあるし感謝の意も込めて、よしブログ書こうと決意。
帰りの新幹線でデブサミ全体の感想をまとめて…力尽きる。
で、今にいたります。
３回目（今回）：SQLアンチパターン・レトロスペクティブ関西に行ってきた
おととい 3/26「SQLアンチパターン・レトロスペクティブ関西」に参加しました。
SQLアンチパターン・レトロスペクティブ関西 - DevLOVE関西
東京のメイン会場をテレビ会議でつないで、大阪からサテライト参加でした。
大阪は15人くらいだったのに対して、東京は100人とか凄すぎ。
まず、和田さんからSQLアンチパターンについての講演があり、
その後グループごとにディスカッションという流れでした。
和田さんの講演では、25個のアンチパターンひとつひとつの解説があり
ひと通り読んだ身として、よい復習の機会になりました。
実はすぐ理解できるアンチパターン
25個あるアンチパターンをひとつ２〜３分くらいで解説されました。
大阪会場では『SQLアンチパターン』を読んでいない人がほとんどで、
読み終わっているのが私だけという感じでした。
それぞれ短い解説だったにもかかわらず、
講演後のディスカッションでは皆さんちゃんとアンチパターンを理解されていました。
自分の失敗体験とすぐに結びつけられたからこそ、すぐに理解できたのだと思います。
本を読んだ時の私もそうだったので。
つまり、それくらいアンチパターンをみんなやらかしているということです。
それらアンチパターンをひとつにまとめた、この本の功績は偉大だと思います。
社内の勉強会であっても、何点かアンチパターンをその場で紹介してディスカッションするといったことも簡単にできるかもしれないですね。
お気に入りのアンチパターン
私からお気に入り（？）のアンチパターンとして次のふたつをディスカッションで共有しました。
・キーレスエントリー（外部キー嫌い）
・フィア・オブ・ジ・アンノウン（恐怖の unknown）
うちの会社の開発では、外部キーを設定しません。
少なくとも私は外部キーを設定しているのを見た記憶がないです*1。
また、NOT NULL 制約についての設計は後回しになっていて、
主キーしか NOT NULL が設定されていないテーブルも多々あります。
それが当然だと思ってました。
外部キーがなくて NOT NULL が少なかったらテストデータ入れやすいやんって。
だだ、データ制約がほとんどないのでアプリ側の制御が必要になってきます。
「（子テーブルに対する）親テーブルのレコードが存在しない場合の制御が必要かも」
「ここには NULL が入ってるかもしれない」
「NULL または '0' のとき、◯◯。'1' のとき、△△」
そういった、余計なモヤモヤした関心ごとが意外に多かったりします。
今回これらのアンチパターンを勉強した結果、データ定義として制約を適切に設定することでデータ制御が明瞭になるということが理解できました。
こんどからはちょっとずつ外部キーや初期値などを使っていこうと思います。
その他のお気に入りはスパゲッティクエリ。
「なぜか SQL の世界だと一発勝負したくなる」…ぷぷっ、まさにその通り。
アンチパターンについてディスカッション
うちのグループのディスカッションでは、DBMS についての議論が多かったです。
（どちらかと言うと、インフラ寄りの人が多かった）
・空文字・null のあつかいが DBMS によって異なるのによくひっかかる。
・トランザクション分離レベルのデフォルトが DBMS によって異なるのに気づかず悩み続ける。
・自分が最初に触れた DBMS がデファクトスタンダードだと思ってしまう。
・インデックスはちゃんと計算して張れているか？張ったら逆に遅くなったり。
などなど…
アプリ開発者として、あまり意識しない領域の話が多くて勉強になりました。
26個目のアンチパターンを考える
ディスカッションの第2テーマとして、新たなアンチパターンを考えようということで
色々とあるあるネタを共有しました。
全体レベルでは次のようなものが共有されました。
ER図もどき
ER図は簡単にルール通り正確に書けるはずなのに…オレオレ書式のER図。
レインボー・クエリ
DBMS依存の書き方が混在して統一されていないSQL。(+) を使ったり、使わなかったり…
日付なのにCHAR型
あるある…CHAR(8) とか、よく見る。
忍者屋敷
トリガーを使いすぎて、予期せぬ連鎖反応が発生。ネーミングいい。
うちのグループでは次のようなアンチパターンを考えていました。
敵の昔のDBMSの都市伝説を信じるな
自分が使っていない製品の過去のデメリットをいつまでも批判材料にする。
「SQLServer は◯◯だからダメだ！」（もうそれ治ってるよ）
バージョン上がるとデメリット解消されてたりするはずなのに。なぜだか目の敵に。
DISTICT 隠し
自分の想定と違うデータ（重複データ）が取れると、とりあえず DISTICT つけて見なかったことにする。副問い合わせとかしてるときによくやりたくなりますよね。
とりあえず列指定
アプリ側で使わないのにとりあえず、必要そうな列も SELECT 句に入れておく。でも将来的にも使わない。インプリシットカラム（暗黙の列）のアンチパターンと似ているかな。
個人レベルで考えてたのは…
１件テスト
自分の想定するデータが１件だけ取得できるテストデータしか用意しない。
本当は複数件取得する、色々なパターンのテストデータを用意すべきですが、通るテストしかしないやつです。
これやると、パフォーマンスを全く考慮していないということにもなるので
後々になって大量データで結合テストしたときに無茶苦茶重いという事態が引き起こされたり。
１件だけしかテストしないというのは極端かもしれませんが、
開発しているときは実際のデータ想定件数を考えながらSQLを書いたりテストデータを用意したりすることは疎かになりがちだと思ってます。
まとめ
あるあるネタが思った以上に多くて、ディスカッションでは結構笑いました。
それだけ、DBやSQLという領域では同じような失敗経験をしているということです。
プログラミング言語は違ったとしても、SQL はだいたいみんな使ってますからね。
講演いただいた和田さん（和田卓人さん・和田省二さん）、ファシリテートいただいた DevLove のみなさん、ありがとうございました。
とても楽しい勉強会でした。３度目の正直でブログも書けました。
*1:たしか astah で ER図書くと、外部キーが勝手に設定されます。イラネーとか思ったり…
