Developing database-backed software, often one finds it convenient to store stuff in the database which one might traditionally express in code, but which is useful to store in the database (so that it can be changed without requiring a reload of the application).For instance, one might have processes which send automated email using a template; it makes sense to store this template in the database, so that the text can be tweaked by the users without having to change the code/redeploy/etc.However, these templates are important- they are required for the correct operation of the system, and for instance, if they become malformed or missing, the underlying functionality would probably stop working. As they live now in the database, they don't outside version control- you might add audit tables to have change history about this information, but revisions/etc. are separate and independent from your main code's revisions.How do you handle this kind of stuff? Not putting this kind of stuff in the database and make changes go through development/change control/deployment cycles? Or something else?Cheers,lex
Database-stored configuration management
database;configuration management
If I got you right, you have data for which may be edited by your users (at least, to some degree), but this data is required for the correct operation of the system and if it becomes malformed or missing, the underlying functionality would probably stop working. There are some things you can do here:forbid your end users to manipulate that data. You can store those data in the database, but your program does not offer any functionality to change it. The only one who is allowed to change that data is, for example, an update installer provided by you when a new release of your software gets deployed. Or, you allow your end user copying of that data and let them manipulate the copy, but never the original thingallow only some special users (admins) to change that data in the database (but beware, admins can make errors, too)add a functionality in your application (or only for admins) to restore that data to its original state provided it becomes malformed or missingprovide a functionality to check if the data is malformed or missing; run this check after someone changes the data, and (more important): run it whenever your program tries to use that dataseparate the parts of the data which can be safely changed by the end user clearly from the parts which cannot (and don't allow users to change the latter)try to make your updates intelligent: when you deliver a new release, including an update installer for your database, th installer should expect data manipulation in, for example, your template table, and act accordinglyIt should be obvious that each of these suggestions can be combined with each other.