変更に強い設計のよくあるパターンを教えて下さい

質問

お世話になります。

とある企業の業務システムの設計をしていたところ、
上司からその設計では、変更に弱いと指摘されました。

具体的には、検索系の画面で、ユーザーがプルダウンを選択する。
選択された値に基づきDBを検索し、結果を画面に出力するというものです。

私の設計はプルダウンの値が、（仮に）Aだったら、where 条件を これと、
これを指定して検索してください。という設計書を書きましたが、
上司からはプルダウンの値が増えたら、SQLを変更しなければならず、
変更に弱いと指摘されました。
上記のパターンでは、どうすれば変更に強いのかを聞きましたが、
それ以外にも皆さんが知っているパターンで、「こういう時はこういうケースがあるから、
予めこうした方がいいよ」といった変更に強い設計のパターンをご存知でしたら
教えていただけませんでしょうか？

よろしくお願い致します。

回答No.2

papapa0427 · ベストアンサー

２つのＤＢを使うようにすれば良いかもしれません。

プルダウンで'A'ならWHERE句を変更する。ではなくて、プルダウンで'A'が選択されたら'A'の値を別テーブルより取得して、その値でWHERE句を生成するようにする、なんて事をすると良いかもしれませんね。

道具建てとしては、PL/SQLなんかもあったほうが良いかもしれませんね。

お礼

ありがとうございます。

例えば、マッピングするテーブルを設けてこんなデータを用意するわけですね。

pulldows_value where_joken
--------------------+-------------------------
A where table.column = 'A' and ...
B where table.column = 'B' and ...

で、プルダウンが増えたら、このテーブルをメンテしていけば、
SQLのロジックを変える必要がないということですね。

他にもご経験からこんなことがあって、こう対処したよ（すればよかった）とかございましたら教えていただけると嬉しいです。

回答No.1

NNori

要するにあなたは、こんな設計を書いてしまったのでしょう？

Aだったら、where条件を これ１と、これ２を指定して検索してください。
Bだったら、where条件を これ３と、これ４を指定して検索してください。
Cだったら、where条件を これ５と、これ６を指定して検索してください。
。。。

これじゃぁ、ダメですよね。
解決法は上司から聞いたそうなので、わざわざ書きませんが、要するに変更に強い設計のパターン
は、いかに想像力を働かせて、パターンを考えられるか？なのです。

自分がやってることを客観的に見ることができるか、も重要です。
客観的に見ることができれば、いろいろなパターンが見えてくるものです。

お礼

はい。その通りだと思います。

客観的に見れるように頑張ります。