Hmmmm. I seem to have struck a nerve. I admit I sometimes fall prey to 'lone-cowboy' thinking; in my defense, this mindset has not been historically catastrophic to me in my environment. I understand that there are some environments where cowboy coding can produce severe consequences, sometimes felt by innocent bystanders. Your mileage may vary.

This is what configuration files coupled with useful abstractions are for. This is not what a database is for.

I'm not sure why you differentiate between configuration files and database storage. Who cares whether the configuration details are stored in a simple file or in an RDBMS? Please help me to understand the importance, in your mind, of this distinction.

Changing the allowable value of a field is NOT a trivial release.

I'm not sure why changing data entry rules are not a trivial release in your estimation. Suppose I currently do business in 27 states, and I add a 28th. Up until now, users couldn't select a particular state from a drop-down list, now they can. I make a change in the table of allowable states, and suddenly data rows start showing up with this value in my tables ... not a big deal. This seems trivial to me. Am I over-simplifying?

Allow me to rephrase: "Because my company actually respects change control, I will exploit a loophole in order to avoid actually managing my changes. Instead, I will unleash changes unto prod in a lone-cowboy fashion."

Your conclusion about my motives is uncharitable and not fully informed, but I'll provisionally accept the rebuke. I will point out, however, that few of us have the luxury of working in a perfect world. I work in a world where 'Change Control Freezes' are routine and where application updates in production are periodically and categorically denied, across the board of the organization. Since I (and my immediate management) find this nonsensical and not in the best interests of the company, I exploit loopholes, to get real work done in the real world. This doesn't mean I don't manage my changes, it just means that I don't manage them in the 'perfect world' way. Since my conduct technically conforms to corporate policy, I conclude that if I can abstract certain data rules into the database, then that constitutes an acceptable level of risk, since the rule loophole exists. It is sort of like finding a little-known legal deduction when filing your taxes, I think. Weaselly, yes. Wrong, no. :)

In reply to Re^5: Migrating database field values rules from Perl code to DB by ptum
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.