SQLアンチパターン

を読みました。

DB絡みで辛い思いをしたことがないという人はほとんどいないんじゃないでしょうか。そんな人が経験と理論を元に作成したのが本書でググれば評価の高さを見ることができます。

そんな中でも今まで出会ったパターンを整理や自戒の意味も含めて挙げてみようとおもいます。

その昔無知だったためにこれで複数の属性持たせられるぜ！とかそんな感じで作ったことがあります。ただ、勉強のためにやっていた事で実際の製品でなかったのが救いです。

考えだした時はこれ以上ないとか思っていたましたが、SQLにはセパレータで分割するsplit(explode?)に該当する関数が用意されてなかったり、WHERE句の書き方に悩んだりと使い勝手の面でも最悪でした。

解決策：状況に応じて適切に調整する

色んな場所で議論されていますが、これが全て何じゃないでしょうか。それを言われたおしまいだとか議論にならないとか言われそうですがはい。

外部キーがないのでテーブル間の関連がわからず、(関連がないんだから)ER図もなく初めて遭遇するテーブル同士の結合には担当者に聞かないと真実は何もわからない。そんなこともありました...。

なんでもマスタとか汎用マスタとか名前がついてるアレ。

欲しいデータを探すにはエクセルで管理されている表(常に新しいとは限らず、内容も合っているとは限らない)から探すか、直接LIKEでそれっぽい名称で検索をかけてからクエリを書く。

遭遇率は中々の高さを誇っています。

値1から値100とか名前のついた列を持つ謎テーブル...。しかも識別用IDによって意味が変わるという素敵な仕様。

注釈にもありますがOracle君は文字列結合の際のNULLの扱いがアレです。それが原因でテーブルにデータはあるのに何もでない！ということもありました。

COALESCEを出すならNULL絡みの時に元気になれるNULLIFの紹介もあると良かったかなと思います。 NULLを回避するのではなくNULLにすることで回避するという目的として。

NULLと仲良くなるとSQLももっと面白く便利になると思います。

GROUP BYをよくわかっていない時に何度も怒られました(今でも怒られますが)。面白かった点は各DBのエラーメッセージ一覧ですね。 Oracle君...。

だ、だって1つのSQLで全部取れって言われたんだもん...。決して狙って数百行の集計用クエリを書いたわけでは...。

別の方法の検討やDBに用意されている集計関数や分析関数を探す事でもっとシンプルに、保守性の高いものに出来るでした。

データがちょっと増えてきた頃から急に遅くなるクエリがありました。原因としてはワイルドカードを使って必要ないBLOB列まで取ってきている事でした。

ファントムファイルを回避するための設計をしたものの楽をしようとしすぎたために起きた問題です。テスト中に発覚したのが幸いでした。

あのシステムどうなったのかな。検索ボックスに 1 or 1 = 1と入れて検索したら素敵なことになってなぁ...。

さすがにDROPを混ぜたものを試す勇気はなかった。

そんなにたくさんの経験があるわけでもないですがこれだけ(省略したのもありますが)出会っていたんですね。

称賛の声の部分にもある通り必ずしもこの本を全てに賛同する必要はないと思いますが、大部分は参考になったり過去の記憶が蘇るのではないでしょうか。

若い人に限らずベテランにも、DBエンジニアだけではなくプログラマにも是非読んで貰いたい内容になっています。