Different options on how to keep a website's preferences?

Question

Hello,

I am in the process of renovating our CMS and I've run into a situation that I don't know which solution to adopt. Basically each one of our clients houses their website's content in their own database. This includes content, surveys, search words used by visitors, menu strucutre, etc.

A lot of the content on our clients' websites is dynamic and they can change them via the CMS. All of this data is saved in a relational database I've designed but I'm running in a few situations where holding these preferences in a table would be overkill.

For example, the CMS allows them to send emails to a list of recipients. They can choose to use our server or they can put in their own smtp server. However, in this case it would be a little overkill to create a table with a column for "mailService" and have it hold specific values since the table would only hold one row.

Here are the few ideas that I've come up with by searching a bit on this site and/or google but I'm not too sure what their pros and cons are:

• Basically hold all the preferences in a table like I mentioned above, something I'd like to avoid.
• Hold all these "single" preferences in an XML file which I'd modify when they change their settings.
• Have a table called preferences with the following columsn: id, preferenceName, value . Each time I'd have a new preference I'd just add it, modify it, or remove it (I don't like this option because I feel I'd have to hardcode too many values... at least from the way I'm seeing the implementation)

I'm kind of leaning towards the XML idea but I'd like to get some feedback from the good community here at Stackoverflow :) Maybe using XML would be a horrible idea for a reason I've completely overlooked or there's a your-dumb-why-didn't-you-just-do-this solution. Thanks for any input!

Answer 1

The xml route works well in the sense that it easily allows new attriutes to be added and allows attributes to be grouped. The downside is that it is impossible to migrate or update preference data using SQL. It has to be done programatically. You also cannot query preferences for individual attributes should the need arise.

All to say, if you are maintaining a small number of preferences where there is no need to query or update them via SQL, xml would work well for you. Otherwise, the name,value pair table in the database would be a better way to go.

Answer 2

I'd say use one database table if you already have that, and split the settings' names into sensible categories:

mail_service:recipients
mail_service:sender
mail_service:smtp:hostname
mail_service:smtp:username
mail_service:smtp:password

Other than that, I much prefer yaml to XML for readability's sake. It's like XML but without all the clutter.

 mail_service:
     recipients:
       - [email protected]
       - [email protected]
       - [email protected]
       - [email protected]

  visuals:
    header:
      text_color: #BBCCDD
      background_color: #FFFFFF

The Symfony YAML class is a fine stand-alone library to parse that file into a PHP array.

You could also use a simple PHP file.

$settings = array(
 "mail_service:recipients" => " .... ",
 "mail_service:sender" => " .... ",    
 "mail_service:smtp:hostname" => " .... ",
 "mail_service:smtp:username" => " .... ",
 "mail_service:smtp:password" => " .... ");

Answer 3

I would go with the XML file (though it doesn't need to be XML--if it were Java I'd use a properties file until I found a reason not to) or a single key/value table (the id field doesn't gain you much unless it's some foreign key to differentiate between different installations).

Personally I like the versatility of SQL and having things self-contained. Using the database doesn't add any complexity that isn't already there (you will get the same level of caching for free, for example, when you would have to grow your own XML cache if performance is an issue). I would choose XML only if the values had a really complex structure that would make manipulating via SQL cumbersome.

I'm not sure why you think you need to "hardcode a lot of values" and specifically why there would be any more hardcoding with a database solution than with a file solution.