読者です 読者をやめる 読者になる 読者になる

ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

2/26(火)、「SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 -」に参加してきました。 #devlove #sqlap

はじめに

 昨晩は東京:神保町は株式会社IIJで開催されたDevLOVE勉強会「SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 -」に参加してきました。このイベントは、先月末に発売された「SQLアンチパターン」の内容を、訳者である和田卓人氏・和田省二氏に解説していただくというもの。


 オレ自身、最近はビジネス系やアジャイル関連ばかりの勉強会に参加していたので、ここまで技術系ズッバシの勉強会に参加したのはかなり久々。しかも自身の興味嗜好もあってフロントエンドの開発ばかりに関わってきたので、DBやSQLは苦手意識が。ではなぜ参加したのかというと、せっかく訳者が解説してくれるんだから、これを機に本の一冊も読んで苦手意識を克服しようと思った・・・のは建前で、あのTDD伝道師の@t_wadaさんが、しかも親子で登壇するという稀有な例を逃してはならぬ!と興味本位で参加したところが大きかったです。


オープニング



 オープニングはいつもの@papandaさんから。
 まずは会場提供頂いたIIJさん、そしてO'REILLYさんに御礼。O'REILLYの高さんからもご挨拶頂きます。





 今回はいつもの「DevLOVEとはなんぞや?」の説明を時間の関係からカットしたんですが、「今日初めてDevLOVEに参加された人?」と会場挙手を求めたところ、なんと3/4近くの人が手を挙げる事態に。「こんな時こそなおさら説明しとくべきなんですけどねぇ」とボヤキが。
 そうはいっても今後のDevLOVEのイベント開催予定だけは簡単に紹介されます。なんと3月は3日に1回のペースで開催するとのこと。週2回ペースとか完全にやり過ぎですな。


 最後に和田さん親子の紹介が簡単にあって、@t_wadaさんにバトンタッチ。「参加者が100人超えるとさすがにキンチョーしますね。」と下がり際に一言。さもありなん。


SQLアンチパターン」解説

 ここからは訳者の一人である@t_wadaさんから「SQLアンチパターン」の解説。


 まずは@t_wadaさん自身から自己紹介が簡単にあり、@t_wadaさんから「SQLアンチパターンの感想は『#sqlap』を付けて呟いてね。」というお願いが。



 上記はデブサミ2013で発表された内容で、今回DevLOVEで解説頂いた内容は、25のアンチパターンを個別に解説した内容が加わっています。今回のものとは異なりますが、参考にして頂ければと。

愚者は経験に学び、賢者は歴史に学ぶ。


       ― ビスマルク


 上記は有名な言葉ですが、実はこれは間違っているという説が。正しくは

諸君は自らの経験からいくらか学ぶことができるという、全く愚かな考えであろうが、余はむしろ他人の失敗を学ぶことで、自分の失敗を回避することを好む。


       ― ビスマルク


 なのだそうです。失敗なんかしないに越したことはない。痛い目なんか見ない方がいい。他の人が踏んだ地雷の場所を学んで、そこから自分は経験したことはなくても、間違った事例として知識で回避する、そんなことを目指して書かれた(訳された)のがこの「SQLアンチパターン」だそうです。


 「SQLアンチパターン」は4つの部、25のパターンで構成されています。ここから25のパターンすべてについて一つずつ解説して頂いたのですが、このエントリではその内容については割愛。Togetterのツイートまとめを確認して頂くか、自力で本を読んで下さいませ。



 訳した際に「なぜアンチパターン名をカタカナにした」かについては、「パターン名を日本語にしてしまうと、普段の会話で埋もれてしまう」「目立つ名前にして、『議論のポインタ』として活用してほしかった」とのこと。確かに「疑似キー潔癖症」「複数列属性」とか言われるよりは、「シュードキー・ニートフリーク」「マルチカラム・アトリビュート」とか言った方が、違和感があって目立ちますね。

 また、あえて中二病っぽい名前にすることで「必殺技っぽくしたかった」「『ここはインデックスショットガンで仕留める』とか遊び心を持って使ってほしかった」というのも面白い話でした。個人的にはこういう中二病っぽい発想は大好きです!
 これには「25のアンチパターンを全て擬人化(スタンド化)したら面白いんじゃないか」なんて話も勉強会後の打ち上げで和田さんとお話しさせて頂いた際にも出ました。(→DevLOVE PUBのみなさん、宜しくお願いします♪)


 アンチパターンとは「べからず集」「間違えあるある集」という意味合いだけではない、というのが@t_wadaさんの意見。アンチパターンを記憶しておくことで、見つけ方を覚えたり、また逆に「アンチパターンをあえて使っても良いシチュエーション」を見分けられるようになるのも、アンチパターンあればこそ、だそうです。
 「SQLアンチパターン」を「べからず集」ではなく、「パターン本」として利用することで「アンチパターンを共有してほしい」「他人の失敗のエッセンスをギューッと結晶化されて、それを自分の知恵にする」「よくダイレクトメールであった『あっ!この問題、進研ゼミで習った!!』みたいな状態になってほしい」と、本の活用法を語られて、解説は締められました。



休憩時間

 和田さん親子のところに長蛇の列が。みんなサイン待ちです。休憩時間だけでは捌き切れず、勉強会終了後もこんな感じでした。



 会場後ろの書籍販売コーナー。こちらも人だかり。オレは会場到着と同時に購入したので巻き込まれずに済みました。LISPの気持ち悪い本(@papanda談)も売ってましたが、買った人いるのかな?




ダイアログ

 DevLOVE恒例ダイアログ。我々のグループ4人中お一方だけがSQLをバリバリ書いている、他はインフラ寄りだったりフロント寄りだったりと、SQLも書けるが経験そのものはあまりなく、今後覚えて行きたい、詳しくなりたい、という人ばかりでした。

ダイアログ1「25のアンチパターンの中で体験したことがあるものは?」

 最初のテーマは「25のアンチパターンの中で体験したことがあるものは?」というお題。


 我々のグループでは一番盛り上がったのは「スパゲッティクエリ」でした。

 FWの制約でプログラム側のオーバーヘッドが多過ぎ、SQL実行の度に膨大な記述を追記するハメになる、だったら一発でデータを引っ張ってきたい、という意見や、そもそもFWがフロントエンド直結で「一発でデータを引っ張ってこないとダメ」という制約が設けられているケースも(これはオレが経験した案件です)。O/R Mapperを使えばその辺は回避できるだろうけど、一方でO/R Mapperを使うことによる副作用もあるので、どっちを取るかは毎回悩ましいところです。

 また「SQLは技巧に走り易い」なんて名言も飛び出してきました。SQL一発で全ての必要なデータを引っ張ってくる快感に囚われてしまうと、なかなか「スパゲッティクエリ」からは抜け出せないでしょうね。

 「スパゲッティクエリ」を用いることで心配されるのは「性能」と「メンテナンス性」。その点は4人全員念頭には置いていましたが、なかなか徹底できてないのが現状のようですね。


 一方で「ここは最初から抑えてたよ」という意見も。お一方は「ファントムファイル」の話で「割と普段からファイルデータはDBにそのまま突っ込んでしまう。SELECTかける時にファイルを入れているカラムさえ参照しなければ性能を犠牲にすることもないし、管理も楽だから断然いい。少々の画像やPDFだったらボンボンBLOBに入れている。」というお話でした。どうしてもバイナリデータを入れることに躊躇しがちなんですが、確かに速度を自分で検証したわけではないし、上手く行っているという実例もあるわけだから、そんなに怖がらずDBにファイルデータを入れちゃってもいいのかもしれませんね。


 あと、「アンビギュアスグループ」についてはOracleが防いでくれた、なんて意見もありました。DBが持つ機能でアンチパターンを回避できる、なんてこともあるみたいですね。

ダイアログ1 発表

 20分ほどで一回ディスカッションをストップして、いくつか出た意見を発表しました。ここではざっと箇条書きで紹介します。ちなみに今回の勉強会はIIJさんのテレビ電話会議システムのおかげで、東京と大阪の2会場同時開催(大阪はリモート、パブリックビューイングみたいな感じ)で、大阪からの意見も2つほど上がりました。

  • Not Null制約のせいで一行もデータが入らないテーブルが出来てしまった(東京)
  • JSONをそのまま突っ込んでたら、何が入っているか分からなくなってしまった(東京)
  • 「オレオレER図」ER図っぽく書かれているが、細かい仕様がちっとも伝わらない(大阪)
  • ベンダ依存で止むを得ずアンチパターンを使わざるを得ない時がある(大阪)
ダイアログ2 「26個目のアンチパターンを探せ!」

 アンチパターンは本で紹介されているものだけではなくて、もっと無数にあるはず。それをディスカッションで探そう、というのが主旨。できれば名前を付けるところまでやれるのが望ましいのとこと。「先にアンチパターンを見つけてくるとは、大阪さすがですね」とは@t_wadaさん談。


 我々のテーブルでは、優先順位が主な話題になりました。「order by」をかければその順番で並び替えできるのはSQLの常識中の常識ですが、問題は「どれを優先順位として扱うか?」ということです。たとえば名前なら50音順とかアルファベット順とか、電話番号であれば数字順だとか、ある程度並び替えルールを設けることができますが、レコード1つ1つは単なる情報でしかなく、その情報そのものに優先順位があった場合、どうやって優先順位をテーブル上で表現するのか、で悩んでいる方がいて、どうやって解決するかについて、たまたま@t_wadaさんも我々の近くを通りかかったので、一緒に混ざっていただきながら意見を出し合いました。
 専用にカラムを用意してそこに優先順位を数値で入れて行く、別テーブルで優先順位を定義してそれと紐付ける、なんて意見も出たのですが、時間切れで結論は出ず仕舞い。自分が実装する際にどういう設計で優先順位を実現すべきかは、今から考えておいた方がよさそうな気がしました。

ダイアログ2 発表

 前回同様、全体で「26個目のアンチパターン」を発表。やっぱり東京と大阪、それぞれから意見を聞く形が取られました。以下箇条書きにて。

  • 「型無しの型」
    • 日付型カラムを文字列型で定義する
      • 正しく日付型にないものが入ってきてしまう
    • 郵便番号を入れるカラムを数値型で定義する
      • 結果先頭の「0」が失われる
  • 「レインボークエリー(通天閣問合せ)」
    • プロジェクト内でSQLの記述方法がバラバラ
  • ニュートラルファット(中性脂肪)DB」
    • 不要なデータや設定が残ってしまう
  • 「忍者屋敷」
    • トリガー連鎖で予測できない挙動を起こす

 大阪のセンスがずば抜けてましたねぇ。「通天閣」を「レインボー」と読ませるこじつけ力はさすがです。

クロージング


 最後は@papandaさんによるクロージング。和田さん親子からそれぞれ一言ずつコメントを頂いたのですが、「ダイアログの話を聞いていると、きちんとDBのあるべき姿を追求し、正しい知識と技術があれば回避できるものが抑えられていない印象を受けた。もっとカッチリした設計を心掛け、原点に立ち戻るように努力していってほしい。」と述べた父:省二氏に続いて「そうは言ってもいろんなことが現実には起こって、今の顧客要件は多様化していて様々なシステムを構築しなくてはいけないので、あらゆるパターンに対応できるよう柔軟な思考を持って取り組んでほしい。」と息子:卓人氏がかぶせるなど、こちらが見ててハラハラする一幕もありました。

打ち上げ


 DevLOVEは普段は懇親会とか打ち上げとかはやらないんですが、今回は珍しくパンダ発信で裏方メンバーで飲み会が開催。オレは事前に情報を掴んでいたので、最後まで残ってまんまと潜り込んできました。たまたま@t_wadaさんとO'REILLYの高さんと同じテーブルだったので、書籍に携わるにあたっての面白いお話を色々伺うことができました。

総評

 冒頭でも書いたように、オレ自身はDBが苦手なので、正直ダイアログで話についていけるかどうかが心配だったんですが、いやぁなんとかなって良かった。お一方バリバリSQLを書いている方がいらっしゃったので、その方に引っ張られる形で話が盛り上がったのは、オレとしては非常にラッキーでした。やー、ホッとした。


 打ち上げで@t_wadaさんとの話にも出てきてたんですが、「26個目のアンチパターン集(みんなが思う26個目のアンチパターンを集めたもの)」の同人誌なりまとめなりが出てくれば面白いのになぁとは感じました。先ほども書きましたが、「アンチパターンの擬人化」みたいな遊び方も面白いですよね。「みんなに遊んでほしい」と@t_wadaさんも言っていました。

 「SQLアンチパターン」という本は、たぶんこの本だけ読まれて終わる話じゃなくて、たぶん「続き」があるんだと思います。読んだみんなの中に「26個目のアンチパターンは俺が列挙してやる!」という思いが芽生え、それぞれから出てきた「26個目のアンチパターン」が無数に集まることで、非常に大きな「“NEO”SQLアンチパターン」が形作られる。今度はその無数のSQLアンチパターンが、その後RDBに関わる人を救うようになる。NoSQLや他の言語にもこの動きは波及するようになるでしょう。「単なる『あるある集』『べからず集』ではない」という言葉には、そこまでの意味があるんじゃないかとオレは思っています。


 ダイアログが終わって周りを見渡してみると、参加されたみなさんそれぞれの顔に、ある程度の「満足感」と、反面まだまだ話し足りなさそうな「名残惜しさ」みたいなものが垣間見えました。おそらくは、みんなそれぞれにRDBSQLに困っていて、もっと楽にしたい、もっと上達したい、という思いが強く強くあるんだと思います。


 だからこそ、「SQLアンチパターン」はこの本を読んで自分ひとりでステップアップするだけではダメで、さらなるActionが必要なんだと感じました。今回参加された方々に限らず、この書籍を手に取った方には、是非ともRDBでめいいっぱい遊んで、楽しんで、困ってもらって、「26個目のアンチパターン」に繋がるActionを起こしてほしいですね。もちろん、オレ自身も精進したいと思います、いつまでも「DB苦手」とか恥ずかしいこと言っていられないですし。