44のアンチパターンに学ぶDBシステム

先日購入した本のうち一冊を読み終わりました。

44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)

Amazonにもレビューを書きましたが、非常に面白く、かつ読みやすかったです。
ここで「自分も体験した！」というアンチパターンをいくつかあげてみます。

5 OLTPなのにSQLが重い

開発中のテストデータが少なすぎたんでしょうね。
本番運用が始まってデータが増えだすと致命的な遅さを露呈したシステムを知っています。

7 データの保持期間を決めていない

社内の既存システムはこのパターンが多いですね。
たぶん意味も無くウン百万件以上のデータを保持しているテーブルとかが結構あります。
これもおそらく開発中にあまり将来のことを考えてなかったんだと思います。

10 バッチがリラン(再実行)できない

本の中では「仕様上、再実行ができないことが明らかなバッチ処理」を指していますが、おいらの担当しているシステムの場合、「再実行してもデータに不整合が発生しないかどうか分からないバッチ処理」ってのが時々あります。
元々の担当者に尋ねても「分かりません」とか言われた日にはどうすれば良いものやら・・・。

12 バインド変数を使っていないSQL

それほど多くはないですが、時々あります。
バインド変数を知らなければ安易に文字列で連結してしまいますよね。
本の中ではパフォーマンスの悪化を懸念していますが、おいらとしては予期せぬSQLインジェクションの発生、つまりSQLの構文エラーが偶発するバグを避けてもらいたいです。

15 データ量の暴力 (インデックス不足)

これも多いですね。
日付の期間指定なんかで検索したくてもインデックスが付いていないからフルスキャンされてしまうとか。
「インデックスを付けすぎると更新が遅くなるから、あとでチューニングすればいい」って言われたことがあるんですが、それもどうかと・・・。
「あとで」が「開発中」ならいいですが、「リリース後様子を見て」だった場合、そのまま放置される可能性が大です。
ここも将来のデータ量や検索パターンを見越して、早めに設計しておくことが重要だと思います。

20トランザクションスコープが不適切

この開発者、トランザクションって分かってねえなっていうお粗末システムが存在します。
更新エラーが発生すると、簡単にデータの不整合が発生するという困ったちゃんです(T T)

27 不法占拠 (使っていないと思われるテーブルが残っている)

う〜ん、これも多い。
元の担当者はあまり意識していないんでしょうが、引き継いだ担当者はいるのかいらんのか分からなくて非常に困ります。
DBもプログラムも使わないものはどんどん捨てるべし！

36 DBに格納されているテストデータ量が少ない/種類が少ない

本番運用が始まって不具合が出たり、パフォーマンスの悪さが露呈したりするパターンですね。
一言で言うとテスト不足、つまり開発者のスキル不足、ということになると思います。

37 見て見ぬふり (改造ではなく、追加によってシステムが拡張される)

これも多い！というか、おいらも時々やってしまいます・・・。
だって元の設計が汚すぎるから・・・というのは言い訳でしょうか？反省します。。。