The changing of a schema (whether a database schema, or something as simple as the definition of a persistent class) over time.  For data which is transient within a program, this is usually not a problem.

But for data which must persist, and which must be usable with newer versions of the software, it can be a big headache.

A couple of useful techniques:

* Store data in text format, and identify all fields by name.  Whether it be ExtensibleMarkupLanguage, EssExpressions, simple name/value pairs, or some other concoction--use of text decouples the stored version from the physical layout of the class/record, and has other additional advantages (see PowerOfPlainText).  Use of fields by name allows you to re-arrange things, delete fields, or insert fields in the middle.

** What about using a table(s) to store schema info? That way one can query, report, etc. about such info.

** ''That's already an extremely common, if not universal, approach, and '''is''' universally demanded by RDBMS gurus such as Codd and Date. It really doesn't go far enough to compete with the other points on this page.''

** Perhaps "dynamic relational" is needed. See MultiParadigmDatabase.

* Add version information.  Some languages/data models support versioning as a feature; in others you may need to implement it yourself.  Versioning doesn't spare you the task of writing migration code yourself, but it makes it possible to do so reliably.

And a few other points:

When encountering older data (using an older schema), several strategies exist on how to deal with it:

* Automatically convert it.  Makes it so you don't have to do the conversion ever again, and you can immediately use newer features of newer version of software.  OTOH, it may make data access that could have been read/only into read/write, and if you need to access it with an older version of the program, you're now out of luck.

* Read anything, write current.  When you save data, always use the current schema; but don't upgrade data which is accessed in read-only form.

* Only new data gets new format.  If reading/writing data stored in the old format, always use the old format.  Only data newly created with the new version gets the new format.

* Ask the user.  Allow the user to specify what format data is saved in; using one of the above options as a sensible default (depending on the application).  For database applications, the "user" in this context is probably the DB admin, and not an end user of the enterprise application.

* Provide reverse migration tools.  These can be a pain to write, and going from newer to older often involves some data loss, but it's useful to users.  (Some companies explicitly ''don't'' do this, as part of a strategy to force users to pay money for upgrades.  I won't say a '''word''' about which companies do this and on what products, but some '''excel''' at this sort of business technique, in order to improve their financial '''outlook'''.   Be careful what software you purchase for your '''office''', otherwise you may end up throwing it--or yourself--out the '''windows'''.)

----
AnswerMe: Anybody wish to provide specific UseCase''''''s?
----
CategoryDatabase CategoryDataStructure