August 22, 2008
Yesterday, I briefly discussed schema flexibility. Today, I’m going to talk briefly about schema evolution. Schema evolution refers to the ability to easily move to a new version of an XML schema. When evaluating vendors, make sure the database management system you choose meets your current and future schema evolution needs.
Consider a situation where an organization stores messages that adhere to one of the major XML standards, like HL7 or FpML. Industry standards are evolving, with new versions of those standards being made available over time. Moving to a new version of an XML standard usually means also moving to a new–and hopefully compatible–XML schema.
If the new version of the schema is compatible with the old version of the schema, you want to make sure that your database management system moves to the new schema with a minimal amount of disruption. At the very least, they should support the ability to move to this new XML schema without:
- Needing to re-validate all of your existing XML documents [… which would be a pain!)
- Needing to change your existing XML documents [... which would be an even more painful experience]
And if the new version of the schema is not compatible with the old version of the schema, you want to make sure that your database management system supports schema flexibility to handle the situation. This situation is sometimes referred to as uncompatible schema evolution.
Again, this is a topic that is often overlooked when evaluating XML storage needs, and one that has proven to be quite troublesome when overlooked.