Storing the configuration in a set of database tables is generally considered an easy way to start a new project - the guarantees given by the underlying schema ensure relational consistency and usually make up for a crude validation mechanism.
But does this approach scale? I would submit that no, it doesn't.
Pretty much any application needs to be deployed in several locations and/or environments. Synchronizing the configuration between these environments becomes a bottleneck - databases don't synchronize easily.
The development/configuration team will next ask for concurency control and easy patch application - what if I screw it up with an update and the entire team is now stuck? Can you roll that back?
Extracting, shipping and applying patches from an environment to another becomes a beast onto itself. No doubt - current databases have mechanisms to extract and apply patches... but do they handle conflicts easily?
Can you see what exact patches were applied? Can you tag the configuration as "certified-august-2013" and see the differences since? Do you have to build that functionality yourself?
Can you make sure your support copy reflects the production configuration? What about the testing and development instances? Do you maintain a reference version somewhere?
So... no, using a database for configuration does not scale, as your needs grow. A database's role is to store data and lots of it.
What to use then? Well, the simple answer is: text files. The more complex answer includes the synchronization mechanism as well... stay tuned and you'll see how to easily manage multiple environments and synchronize configuration across them, in part 2.