pg TAKA blog

唐突ですが復活。

SQLアンチパターン http://www.oreilly.co.jp/books/9784873115894/ で紹介されているパターンの中で割と議論を巻き起こしたと思う"IDリクワイアド"。
普段相手にしている某会計システムや、フレームワークなどではID列を使用するのが当たり前なので「なんでこれがアンチパターンなの？」って思ってたのですが、去年の某大規模プロジェクトで見てしまった。本当に定義通りの「IDリクワイアド」を。

・プロジェクトの規約により、全テーブルにID列を作ることになっている。
・ところがID列を含めてあらゆるインデックスがユニーク／ノンユニークを問わずに張られていない。
・IDでの結合がないわけじゃないがまっとうじゃない使われ方をしている。
・そんなテーブル群なのに一度のトランザクションで数百万レコードの更新系を扱うことがある。

で、それを核としたう○こちゃんなDB設計でパフォーマンスが出ないとか言うわけですが、SQLも悲惨そのもの。
多段副問い合わせに１０連結以上のUNION（しかも一つ一つのSELECTが100行レベルのビミョーな違いのコピペコード）、無意味なDBロック。
IDだからといって、わざわざシーケンスを連番保障で発行をしているせいでDBクラスタの同期待ち発生させまくりというバカっぷり。

実はインデックスが無い件などは別のありえない「やんごとなき理由」によってそうなっていて、これはこれで一ネタかけるのだが・・・

ほんとあの会社、爆発しねーかなー