SQLアンチパターン・レトロスペクティブ関西・リターンに参加して来ました

http://devlove-kansai.doorkeeper.jp/events/3022

初めに、会場を提供していただいた楽天さん、DevLOVE関西の運営に携わられたみなさんありがとうございました。

SQLアンチパターンの監訳者である和田さん親子（親子！ってのがすごいな）に来ていただいて 直接話しができるという事と、典型的なSI系の仕事に従事している自分でもドヤァできる話題だという事で参加を決めたのですが、予想以上の収穫があったように思います。

SQLアンチパターン

最初は和田卓人さんによる各パターンの解説から始まり、グループに分かれてアンチパターンの内、実際に自分達が経験したものについてディスカッションを行った後、共有というのを2セット行いました。その後26番目のパターンを考え、大質問タイムでは和田卓人さんにそれぞれ出たパターンに対してコメントしていただき、和田省二さんによるモデリング技法の講義に発展したりとすごかった。

最初のディスカッション（5人）

なかなか話がまとまりませんでしたが、一番盛り上がったのは「23章ディプロマティックイミュニティ」で、「DDLはVCSのリポジトリに入っているのに、DBを直接GUIツールでいじってしまう事があった」や「アプリケーションとDBのライフサイクルの違いが原因なのでは？」、「DBAが特権を持ってて手出しできない事もあるよねー。」と言った話が次々と出て来ました。 その時はどうすればよかったのかという話ができませんでしたが、これは本当に本に書いてある通りで継続的デリバリー等のベストプラクティスに乗っかるしかないなぁと思いました。 5章EAVの所ではNoSQLの話になり、「RDB」ってなくなるの？てきな話題が出たけど 住み分けが進むんじゃないかという結論にいたりかけたところで、和田卓人さん登場 「うんうん」と頷いておられた。 これで少し人見知りである私のテンションが若干上がった気がする（笑）

2回目のディスカッション（3人）

割りとまとまった話ができた。私は…。ここでは私が「10章サーティーワンフレーバー」の関して 一人で盛り上がってしまった感があり若干申し訳なかったり…

列に登録できる値を制限したいという目的に対してその値を別テーブルに切り出し、 参照整合性制約つけたらいいよって話なのですが「テーブル増えるやん」「そもそもテーブル増やす事に対する心理障壁でかいよな」とか「テーブルに切り出して変更されたら怖いやんとか」「画面のコンボボックスに表示する選択肢取るのにDBアクセスするのはめんどいやん」とかそんな感じでした。

26番目のパターン

私のテーブルでは、「リサイクルクエリ」というパターンができました。

• 見つけ方は見たらわかります（やる前にわかれ
• クエリを再利用するのが目的
• 生のSQLをSELECT、FROM、WHEREでバラバラに分解して無理やり構造化してしまい、可読性が犠牲に
• 解決策はORMのクエリビルダを使うなりしましょうということでした。 　（後の和田卓人さんから頂いたコメントではチームでちゃんとルールを決めて それに基づいた構造化をしましょうとの事でした。）

和田省二さんによるリソースとイベントの見分け方の解説

自分が割と詳しく知っているドメイン領域に適用しやすいはなしだったので かなり勉強になった。

• 「Entityを見つけたら、必ずResource/Eventに分けましょう」
• Event - 時間の進みに従い発生するもの。過去の記録。
• Resource - もの。未来の為に登録しておき、発生日時、消滅日時といった期間を持っている事が多い。
• 多対多の関係で定義する交差テーブルはEntityになる
• 交差テーブルでも多対多、多対1、1対多、1対1と多重度はビジネス要件により様々ある
• 多重度重要

懇親会

色んな踏み絵がいっぱいで怖い懇親会ではあったが 世代を超えた交流！ができた。 後半は正直かなリ酔っていてみなさんに失礼な事をしていなかったか心配だ…

以上！