You have a very large number of entry fields with a large number of similar attributes, and you want to simplify your application code.

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

You expect the allowable values for some of the fields to frequently change over time, and you'd like to avoid multiple trivial releases of your code.

Changing the allowable value of a field is NOT a trivial release. If you allow a value that goes over an edge case, then you have introduced dirty data. Dirty data is almost always impossible to get out.

You need to be able to re-configure your application on the fly in a distributed environment.

This is the ONLY relatively sane reason to put application logic into a database. And, there are much better ways of accomplishing the same thing. The only thing a database brings to the table is the centralization. Centralized datastores aren't necessarily a full-on RDBMS. For example, a simple DBM::Deep or BDB file on a NAS would be perfectly fine for things like this.

And, I've saved the best for last ...

Updating your code in production is fraught with red tape; in some corporate environments, database changes can often sneak under the wire, avoiding onerous (but unsophisticated) bureaucratic constraints.

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."

Change control exists for a reason. Often, it's because you do NOT understand the ramifications of your changes. Furthermore, even if your bureaucracy should be avoided, you are breaking your application design. Assuming that this is a good plan, it is a consequence and not a reason. It's like saying "Eating a bowl of sugar is good for my health because it's better than eating a bowl of lard."

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. :)

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?