プロが教えるわが家の防犯対策術!

お世話になります。

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

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

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

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

A 回答 (2件)

2つのDBを使うようにすれば良いかもしれません。



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

道具建てとしては、PL/SQLなんかもあったほうが良いかもしれませんね。
    • good
    • 0
この回答へのお礼

ありがとうございます。

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


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


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

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

お礼日時:2014/02/15 16:59

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



Aだったら、where条件を これ1と、これ2を指定して検索してください。
Bだったら、where条件を これ3と、これ4を指定して検索してください。
Cだったら、where条件を これ5と、これ6を指定して検索してください。
。。。

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

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

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

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

お礼日時:2014/02/15 17:13

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!