アプリ版:「スタンプのみでお礼する」機能のリリースについて

業務システムを自社で構築、メンテをしていますが、ソースの中の条件文などに社内コードを直に書くのは間違いでしょうか?保守性を考え、そういったものは全てDBのフィールドを追加して管理すべきと言う人もいますが、個人的には頻繁に条件の変更があるのならば(例えば品目コード等)DBで管理すべきでしょうが、なんでもかんでもDBで管理するのは抵抗があります。
皆様はどのようにされているのでしょうか?
また、DBで管理するデメリットがあれば教えていただけますでしょうか?

A 回答 (3件)

昔からよくある話ですね。


sinsouさんのお考えも分かります。
ところがです。
sinsouさんがその業務システムのメンテを最後まで担当するなら、それでもいいと思います。
しかし、仕事はいつ別な人が担当するか分からないですね。場合によってはsinsouさんが転職のため退社してしまうかもしれません。
ですから、会社ではいろんなリスク・ヘッジを考えるのです。別な担当者が急にその社内コードの変更作業をしなければならないとすれば、どこを直せばいいのか苦労しますね。最終的にソースコードの中に入っていたと分かるでしょうが、DBやテーブルに格納してあれば簡単に見つけられますね。
業務システムによっては40年位動いているものもあります。
次世代の担当者のためにDBなどに統一していた方がいいのではないでしょうか。

この回答への補足

ご回答ありがとうございます。
例えば、とある取引先2社のみ特殊な処理ををしたい場合は取引先コードは書かず、取引先マスターに区分を追加して、2社のみフラグ1を立ててそれで判別するようなイメージでしょうか?また同様の処理をする場合はどんどん区分を増やしていくでしょうか?

補足日時:2014/04/19 22:11
    • good
    • 0

No.2gouzigです。


補足コメントの内容、そういうやり方になると思います。
そのような方法だと、取引先マスターに区分を追加するDB変更が多発してしまいます。
それでは大変なので、あらかじめ取引先マスターには区分欄を多めに作っておきますね。
そうすれば、都度DB変更作業をしなくて済みます。
    • good
    • 0
この回答へのお礼

ありがとうございます。
参考になりました。区分を追加することで対応していきたいと思います。

お礼日時:2014/04/19 23:50

>品目コード等


その手のコードは他の項目とリンクすることで意味をなすものですよね。であればRDB上でリレーションが張られ、品目コードの存在しない商品マスターは作れないとか、売り上げデータなどのトランザクションが存在していれば、そのコードは削除も出来ない、もっと言えば、トリガーで管理され、品目コードが変更されれば売り上げデーターの品目コードも一斉に書き換わるなどの、ビジネスルールを書くことも可能で、これらはRDB上でのロジックになります。
これらをプログラムなんかで制御しようとするのはまったく無意味になりますから、この品目コードをソースに書き込むのは二重管理になり、整合性の低いシステムになると思います。
そうではない設定情報などなら、XMLファイルで管理し、読み込んで処理するのは普通です。また最近はネット間のリンクが一般的になりつつあり、複数のサイトのXMLデータを読み込んで使いますよね。株価情報や企業情報などです。
これらはネットのURLを通じてXMLで別々に取得され、メモリ上でリレーションを掛けられメモリに対してクエリを掛け処理します。まあこれが現在の常識になりつつあります。RDBではネットでは不都合が多く使えないからです。ビックデータなどの処理はこういう処理です。
つまりソースに書き込むなんてのは今ではあり得ない領域で、ソースコードさえも実行時ネットで取得して補完することも普通に行われてます。
    • good
    • 0
この回答へのお礼

やはりそうなんですね
ありがとうございます

お礼日時:2014/04/19 23:46

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