『44のアンチパターンに学ぶDBシステム』を読んだ

　現在のプロジェクトのDBのテーブル設計に疑問を持っていて､フラグを複数もっていたり､ユーザの種類を数値で管理していたり､具体的に言うとユーザがフォームで設定を保存できて､例えば

みたいなテーブルが存在する｡

そしてtype1はparam1だけを使用してparam2~3はNULLで保存､type3はparam1~4まで使用するみたいなテーブルになっている｡

本当にこれでいいのかわからないため､どうするのがベストなのか知るためにデータベースのアンチパターンや設計の本をいろいろ読んでいる｡

　その1冊として『44のアンチパターンに学ぶDBシステム』を読んで見事にアンチパターンにハマっていて､わかりみが深かった｡

基本的な構成として､

設計･アプリケーション･SQL文･インフラ設計･運用･テスト･プロマネの問題･人的問題･組織の問題に大きく分けてアンチパターンが紹介されている｡

　それぞれのアンチパターンは説明(どういう状況か)→挿話証拠(あるあるな会話)→頻出スケール(どこで見られるか)→再構想解(どうすればよいか)

といった形式で説明されていて､例外として使用していい状況も書いてある｡

　また筆者の体験に即しているそうなのでストーリーとして読めるので､非常に共感できるし､まさに今このアンチパターンの状況なんだが･･･あばばばばっbと思って悲しい｡

　特にアンチパターン｢目標なきチューニング｣で､チューニングしてもパフォーマンスが達成できない場合､システムアーキテクチャの変更は大幅な見直しが必要になるので､インメモリDBを使用して処理を行うとか､そういうことまさにやってたなぁと｡

　自分にとって初めてのプロジェクトで､現在の状況が正常なのか異常なのかわからなかったけど､やっぱり駄目だったんだなとわかった､また信用できる人がいないのでどうすればいいか自分で考えて良くしていくしかないかなと思った｡

　本書を通して全体的に､設計が不十分･マネージャの理解がたりない･工数が足りない･テスト不足が､問題を引き起こす大きな要因になっていて､自分の力ではどうしようもないレベルのように感じる｡

　アプリケーションに比べてデータベースの変更は影響の範囲が大きくて重い作業なので､なんとかしたいと思っているのだが･･･｡

Vapor Trail