弊社では有志でSQLアンチパターンの読書会を実施しています。週一回、1章ずつ、1ヶ月で4章分を実施してきました。

今でこそこんなことはやらないだろうという話でも、実は昔自分でやってしまったことがあるとか、誰かが経験したことがあるといったパターンもあり、心にぐさっと刺さる話もありました。

今回は既に実施した第1章〜第4章について、まとめと感想を書いていきたいと思います。

1章 ジェイウォーク

カンマ区切りとかで複数の項目を1カラムに入れ込んでしまうジェイウォーク。これは検索がツラい、インデックス使えない、JOINがツラいなど、ツラいことばかりなので横着するのはやめようねという話です。
個人的にはこれまでジェイウォークをやったことはない (気がしています) ですが、今後ともやることはおそらくないでしょう。
基本的には、ジェイウォークが必要になる状況はかなり限られるのではないかと思います。

2章 ナイーブツリー

そもそもRDBに階層構造を格納するのは難しいのですが、本ではナイーブツリーとして紹介されている隣接リストの他に以下の手法が紹介されていました。

• 経路列挙
• 入れ子集合
• 閉包テーブル

これらの手法はそこまで単純でもなく、ナイーブとして紹介されている隣接リストについては、再帰クエリを利用すればツリーへのクエリ実行もそこまで複雑になりません。MySQLなどでは利用できませんが。
というわけで、結論としては隣接リストというのはそこまでナイーブなやり方でもなく、ユースケースを洗い出し、どういうクエリが必要になるのかを慎重に判断した上でデータ構造 (およびデータベース) を決めるのがいいと思います。

また、読書会では階層構造をRDBで扱う第五のモデルとしてFertile Forest Modelというものがあることも知りました。
詳細は
http://qiita.com/StewEucen/items/e0487c39285a9d6b7863
などをご参照ください。実際に将来的に利用することがあるかどうかは不明ですが。。。

3章 IDリクワイアド

結論としては、id列はあってもなくてもどちらでもいいのではないか、フレームワーク側に合わせてid列を付けることにそこまで害はないのではないかという話になりました。
確かに、例えばRuby on RailsでActive Recordを使っているような場合、idカラムがあったほうがかなりプログラムは書きやすいです。

4章 キーレスエントリ

外部キーは面倒がらずにきちんとつけておこうという話でした。これについても特に異論はありません。
確かにテストのときなどで複雑なデータ構造を作る時に外部キーがあると面倒だったりしないでもないです。ただ、そこはきちんと自動化するなりして対応しようという話になりました。
以前、ゆるゆるのデータベースのシステムリプレースを行ったことがあり、その際に整合性が取れていないデータが多数あって非常に困ったことを思い出しました。それを踏まえても、外部キー制約はきちんと付けていこうと改めて思った次第です。

今後、引き続き5章からを実施していきますが、いい復習になりますし、楽しい議論もできるので、今後も楽しみながら参加していきたいと思います。

shimo