Site Configuration Params In Config/main.php Or Database?

As the project grows, I find that many configurable things, like how many rows a datatable should show at a time, the mail server address…are scattered in many different files, after some time, it may become hard to change these parameters as I forget where they are or the same parameter may exist in several places. So I think about the ‘params’ section in the app-wide config file, and it probably will suit me needs, but I’m not sure.

My question is–If the project has a lot of configuration params, would it be better to store them in the database? which option has better performance?

Great question. I think some of this is about personal preference, so I’ll state my own.

By far I prefer storing config params in a file. Several reaasons:

In a file, such params are easy to maintain in revision control (git, mercurial, svn, etc.)

In a file, I can easily grep for parameters, and change when needed. There’s no need for me to know the structure of the database. This is especially a lifesaver when you check out a project you worked on a long time ago, and you have no working local database.

I usually set up a main config.php which includes other config files as a function of things like the local environment (linux, mac, etc.); the $USER variable, etc. By storing config params in files, it’s a snap for programmer Suzie to have her own set of configuration parameters, and when she changes her params, it doesn’t affect my environment. Her params are in the file user-suzie.php; mine are in user-emily.php. The site-wide parameters which neither Suzie nor myself should change are in the main config file.

Here’s another forum post on similar topic -

http://tinyurl.com/b4qsp3a

I disagree with what “redguy” states in the post above (that he maintains local config files that he never checks into revision control). It’s always better to check stuff in, IMHO, and take proper security precautions (e.g., accessing git etc. via ssh). This allows you to check out a project months after you’ve used it, and have a local environment up and running very quickly.

Useful tip. Thanks for sharing.

I find settings extension quite useful in this situation, in a case of big number of parameters using approach I described in the comment.

Important notice - all parameters are cached with this extension, so performance won’t be an issue.

I only put settings that need to be configurable by the users into the database. Pretty much all configuration goes into the config file.