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

Question

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.