監訳の一人である @t_wada に献本頂きました。 ありがとうございます！！！

でだ、いきなりだけどコレ、タイトルで損してると思うんだよね……

だって、SQL のアンチパターンてタイトルだったら、

join した結果の方で where で絞るよりも on 句で先に絞れ

的なのが書いてあると思うじゃん！！ 問い合わせ言語の事だと思うじゃん！！！

違った……

ほとんど書いてあるのは DB 設計についてだった…… まぁ、副題は「Avoiding the Pitfalls of Database Programming」のだし、まぁいいか。

んで、読んでみた感想とか

もうね、何年か DB 絡んだ開発したことのある人なら（・∀・）ﾆﾔﾆﾔ出来ると思う。

「”マルチカラムアトリビュート”とか 10 年前に通ったわー」

とか

「あーはいはい”インデックスショットガン”乙」

みたいな。

Explain の結果も見ないでインデックス貼りまくる奴いるよねーーー

とか、ドンドン盛り上がれそう。

実際俺も”EAV（エンティティ・アトリビュート・バリュー）” はホントつい最近もやろうと思った。 (結局複雑になりすぎるからやめたけど)

個人的に反対なアンチパターン

ファントムファイル

ファントムファイルの解決策については実際に 2 度やったことがある。 データの規模も、ユーザーの想定数もぜんぜん違う 2 つのアプリで…… でもそのファイルへのアクセス方法とか逆に複雑になるだけで何も得しなかった。 よく考えればファイルシステムそのものがファイルを扱うことに特化した KVS 的なものなんだからそっち使ったほうが良いというのが俺のプラクティスだなぁ

反対では無いけどあんまり賛同しないアンチパターン

キーレスエントリ

外部キー制約で、

オーバーヘッド、……にはなりません

って書いてあるんだけど、いやなるでしょ…… どの程度の更新頻度を見ているのかわからないけど、ソーシャルゲーム系とか外部キー制約とか貼ってたら無理な気がするんだけどどうなんだろう？

ここは本当にこの文章を鵜呑みにしないで、設計時にちゃんと想定ユーザー数で負荷テストやらないと怖いことになりそう……

で、この本の本当に凄いところはパターンに名前を付けたこと

さて、ここまで読んでもらえばわかると思うんだけど、この本の本当に凄いところは パターンに名前を付けたこと だと思う。

俺が書いたみたいに例えば「ファントムファイルは俺は反対だな」的な事が簡潔に言えるようなことになったのは本当に素晴らしいと思う。 今までだったら「ファイルをさ、DB にデータとしていれるパターンあるじゃん！！いや、パスじゃなくてデータ自体をだよ！！ ほら、入れておくとカラムのデータとの整合性を保つのが楽だとか…… 」とかそんな説明をしてからじゃあ無いと議論が始められなかったのがサクッと始められるようになった。

というわけで、タイトルに書いたとおり戦争の火種になってくれそうな本だなぁと。 逆に今までは何度か DB 設計したことないとこういう議論が出来なかったのが本にまとまってくれたのでこれで誰でも議論に参加できるね！！！

p.s.

付録の 第 4 正規形とかの例が凄く良かったです！！（個人的に不得手な所だったので）