A configuration file is (usually) read at application startup. A database field is (usually) read on-demand. If an application is long-running, changing a database field can have disastrous consequences. Note: "can" means "greater than 1-in-10_000 chance".

Let's take your 28th state example. If you add a 28th state, you probably have to add some more code to handle things like the appropriate tax rates, shipping rates, and various accounting rules needed for your 28th state. You probably also need to add product restrictions, commission changes, and various other things. It's never just "flip a switch and turn it on."

As for application updates being refused, I still maintain that you may not have all the information. While there are stupid people everywhere, stupidity is relative to the topic at hand. I once found a bug in a shared application that was causing my application problems. I read the code, wrote a patch, and was able to prove the patch was mathematically correct. The change was denied, and the denial was correct. By changing the app that some 30 other apps depended on, the testing burden for all those changes was herculean. While the change most likely would not have adversely affected the running of those other apps, it might have and no-one was willing to take the risk of losing the company millions of dollars.

So, while I was correct in my patch, the people refusing to apply it were also correct, even though they were "against" my correctness. Sometimes opposition is in skew.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

In reply to Re^6: Migrating database field values rules from Perl code to DB by dragonchild
in thread Migrating database field values rules from Perl code to DB by punch_card_don

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.