Application config: files or database?

void_function

I have a conceptual problem. In your experience, is there a benefit of file-based application configuration over database-based?

I am writing a PHP application that will have to store its configuration somewhere. There are two configuration levels:

The core config which HAS to be in file, as it defines database presence, authentication, etc...
Dynamic config which can be in files or in database.

The dynamic config is stuff like site name, default template, templates list, languages, modules, etc... This configuration is made during installation, but it CAN be changed later from the admin panel.

The only benefit of files I can see is that the file can be cached by the opcode cacher, since the configuration would be PHP, like:

$config['somevar']= 'somevalue';

I believe this is faster than using a database, since the application can use many databases, not just MySQL, including a flat-file database. Yes, there is SQL caching, but that is not to be dependent upon, especially on shared environments.

Thoughts?

redrage

I never had to do it before but i would make a separate DB table for the config.

To me, setting up MySQL for reading and writing information is easier than files, THAT is the only reason i would do it. I'm sure there are a lot of opinions on this though 🙂

MarkR

Normally I would say, store the config in a file. Files can be versioned in your SCM and are not considered part of your application data. This is good.

Of course some data which are configured BY the user might be stored in the database. But doing unnecessary queries on data which change rarely may be inefficient.

On another hand, if you're writing a large scale application, placing configuration data in a database enables it to be in sync from any location within your service (say you have a large number of servers of different types).

Local caching of such data etc, might be a useful optimisation, but don't do it unless you need to.

It's a tricky one.

I wrote an application which had two .php configuration files, one which was set up per-application, another per-instance. The difference? If the application is moved to another server, or some other similar data change, the per-instance data change. The per-application configuration data were things which were configurable at the code level but were notionally versioned with much of the rest of the application's code.

So for me it's all about:
- Frequency of change (things which change often may benefit from being in a database)
- Whether it needs to be in synch between different parts of a large application or service
- How you plan to version the configuration data (if at all)

If it's necessary for it to have a particular value for the application to function correctly (e.g. bits of business logic coded into constants or data structures), it is a good idea for it to be in a file which is versioned with the rest of your code base.

I hope this gives some ideas.

Mark

MarkR

On another note, if you do a code update which depends on a configuration update (e.g. a new mandatory configuration variable being introduced, or some change in configuration scheme) then it's useful to be able to atomically introduce the required config change.

Doing programmatic updates of a non-versioned piece of data in your database requires more work (you need to write and test change scripts / rollback scripts), whereas a change to a versioned config file can be pushed out by your normal deployment mechanism.

Mark

PHPycho

can anybody provide a good sample for db based configuration ?
thanks in advance

edraynham

Create a table:

create table config (
conf_name varchar(50) not null,
conf_value varchar(100) not null,
primary key(conf_name)
);

and then in your common.inc file do something like

<?php

// get config

$q = mysql_query("SELECT * FROM config");

while ( $row = mysql_fetch_assoc($q) )
{
  define($row['conf_name'],$row['conf_value']);
}

?>

I always use constants to define my configuration values within an app because then you don't need to worry about the scope of the variables, as they are always global.