I didn’t get much feedback on the value of writing software so that multiple versions can co-exist. Either it isn’t worth the extra effort or cost to write code in this fashion, or there really isn’t a need. Personally, I have found that there are rare instances where you simply end one version and begin a completely new version of software. There is always, at least for a short period, a time of overlap when both versions are available; even during transition.
Because of that experience, I thought I would turn our attentions to the problem from a database perspective. Unless your database has no internal logic, it can be difficult to design a database with different behaviors. For example, it is fairly easy to have a database with a different table design. Your data access software can be versioned, and address the appropriate tables. Sometimes you might need to use triggers to keep everything synchronized, or allow null values when using the previous version code.
The more difficult aspects are those database business rules implemented in the form of functions, imbedded code, or stored procedures. Unlike object oriented code, you have to be the person that handles the different implementations from one version to the next. How do you do that? You can have a different version of a stored procedure, and have your application code call the correct one. That’s probably the easiest. I have also seen parameters passed into stored procedures, enabling different behavior and business rules within a single stored procedure. The same can be done in functions.
How do you think we should implement different behaviors in our databases? Should we simply not use stored procedures? Should we pass parameters to drive behavior? Should we have different procedures for the desired behavior? Do you have another, even better solution? Share your thoughts with us in the comment section. Let’s hear how you solve the problem.
Cheers,
Ben