Managing important runtime business logic with regard to a codebase

Question

I'm working on a project which will end up have a lot of application information stored in the form of records in a database. In this case, it's the configuration of data views:

• which grid columns to show/hide
• default filters to apply to each grid view
• column titles
• sorting
• subtotaling
• ...

This information is a big part of the value of the application and is essential to it's function. The data will be altered by admins a fair amount, so it's not static and it wouldn't be appropriate to have to deploy a new version of the app every time the data changes.

The question is, Where should this data be stored? It will definitely live in the database because that's how it's accessed, but I feel like it needs to also be kept with the version controlled codebase because it's an integral part of functioning of the application. Has anyone dealt with an issue like this before? What did you end up doing?

Answer 1

You should store it the same way you store the schema definition for your current version. I would export the entries as insert statements and save the file in source control along with all others.

Answer 2

Since this will be in a database that you should be making backups of (nightly backups of the database with transaction log backups every 15 minutes or half an hour), I don't think you will lose the data. Make sure your dbas know how to restore the data to a separate database so you can copy only the table over from that database if need be to recover the table.

Alternatively, you may want a trigger which will store all changes to the data in an audit table. Then you can use the audit table to get the data back if need be (but still do the backups!)