ひどい設計は頭をおかしくします。
ヘタなプログラム(たとえばブロックが長過ぎるとか、重複が多いとか)もデバッグに苦労しますが、ほとんどメリットが感じられないのに開発者の自己満足としか思えないくらい、技巧的な設計の上に構築されたシステムもまた超厄介です。
昨日はそんなシステムのデバッグをやってました。
普通にテーブルA、B、Cと作ってJOINすればいいのに、なぜか一つのテーブルにすべてのデータを突っ込んで、区分でデータを分けてました。
そしてSQL上は同じテーブルの中でJOIN(いわゆる自己結合)が繰り返されます。
区分が4ならA、7ならB、9ならC・・・とテーブルに並ぶデータを見るたびに頭の中で切り替えなければならず、階層が3を超えると、とても頭の中で追いかけることができません。
そして、バグの原因は区分を指定せずにテーブルをJOINしていたことが原因でした。
最初からテーブルを分けておけばこんなバグは発生しないでしょう！？
会社の組織図のように階層数が特定できないツリー構造とかならまだ理解できますが、この場合は親子関係が有限だから一つのテーブルにするメリットはないはずです。
たとえ親、子、孫、ひ孫・・・のようにテーブル数が増えるのを嫌いテーブルの数をケチって1つにまとめたって、それは何を節約したことにもなりませんぜ！
このシステムは以前書いた「一覧にカラムを一つ追加する」システムと同じなのですが、設計、プログラム、どこをとってもヤヴァイです。
なのに社内では頻繁に使われている重要システムです。
最近はレコード数が増えすぎて非常に動作が遅いようです。
しかも複数ユーザーによる同時実行処理を全く考慮していない様子で、更新時も検索時もブロッキングが多発して何かボタンを押すたびに数分待たされるみたいです。
更新時に至ってはブロッキング後にデッドロックが必ず発生するようになっているので、ロックが取得できなかったユーザーさんは全員更新処理がエラーで失敗します。
WEBなのにある意味シングルユーザーシステムですか！？
こんなシステムをほとんど文句も言わず使い続けている多くのユーザーさんたちが不憫で仕方ありません・・・。
このようにお粗末なシステムは将来の担当者への「負の遺産」となってしまうので、新規システムを設計・開発するエンジニアは十分気を使ってほしいものです・・・。
