DB設計のアンチパターン回避の妨げになる政治

今月のＤＢマガジンの特集「14のアンチパターンに学ぶデータベースの開発/運用」

DB Magazine (マガジン) 2008年 12月号 [雑誌]

なかなか面白かった。もちろん、いまさらこんなアンチパターンを「ふんふんなるほどね」といって読んでいるようじゃしかたないんだけど、雑誌で特集されるということは、今から学ぶ人向けなのか、それともアンチパターンにはまってやられちゃっている人が沢山いるのか。前者だと願いたいものだけれども、今まで現場を色々と見てきた経験上、経験豊富なSEでもやられちゃっている。
DBとSQLというのはもはやアプリケーション設計の一環として必修科目みたいなものだけれども、でかいシステムで作業分担していたり、小さいシステムしかやっていない人が突然でかいシステムをやったりすることで嵌まるパターンもありそうです。

しかし、アンチパターンって個人の努力で回避できないことってあるのよね。特にDBというのはそのデータが他のシステムともからんでいくから、過去の遺産含め、今更どうにもならない場合というのもあります。もっと悪いのは、ずっと続いているプロジェクトが初期の設計ミスとか政治的な問題をずーっと引きずっていて、もうどうにもならないこと。アンチパターンとして上げられている「大量インデックス」な状態なんて手に負えない。一つのDBを相当数のアプリケーションが触っているときの影響調査なんかも大変。
かといって、「データが少ないうちは良かったが…」みたいなパターンを回避するために、データが絶対大きくならないようなTBLにゴージャスな設計思想を適用するのも無駄ですね。
技術者の能力不足によってアンチパターンを作りこんでしまう、というのはとにかくワーッと作れ！っていう初期構築のときに一番起こりやすい。本当は、初期構築のときほど設計をきちんとしなければならないんだけど、HW費用やその他イニシャルコストがかかる初期構築では時間と予算の制約によって十分なインスペクション・レビューがなされない状態のものが出て行くことが多い。そんなのあとあと、っていうんだけど保守フェイズではすでに予算的に再構築するにはハードルの高い状態になっている。むろん、既存のシステムを全面再構築するときも、設計を変えますよ、というと過去の実績がどうだ関係システムがどうだといって渋る人がいる。じゃあ再構築なんてする意味がないじゃんと思うわけですけれどもね。
システム開発における悪い政治力は巨大なシステムほど大きい。動いているものが止まってしまうというリスクは確かにあるけれども。いやね、ベンダーが昔のものをちゃんと保守してくれるなら再構築しなくていいシステムなんて世の中いっぱいあるのですけれども。