Object Oriented Databases Schema Control and Data Migration
Schema Control and Data Migration: SQL databases support fixed numbers of columns in tables. When the number of columns changes, generally all the rows of the table must be migrated immediately to the new form. Simple operations like deleting a column can even require burdensome migrations that include copying the entire table. During this operation, the table will be unavailable to users.
Objectivity/DB users are given more choice for schema evolution and data migration. In each class. Each type has a set of shape numbers each of which is unique in the schema across all the classes.
Each object in Objectivity/DB has a shape number to describe its class including its version. Consequently, the type can evolve into a new shape without immediately affecting any of the objects.
As objects are used, Objectivity/DB will detect if the shape number of the object has been evolved. If it has, Objectivity/DB will evolve (migrate) the object into the new shape and change its shape number to the evolved one. If the migration requires adding primitive attributes, those attributes will be added with default values that can be defined in the schema.
If the migration requires deleting attributes, Objectivity/DB will simply drop the data from the object. More complex migrations can be defined with callbacks defined in the application that allow you to read the object in the old shape and migrate it to the new shape yourself.
Objectivity/DB applications can therefore defer all data migration until the migration is necessary and when the data is already being read into the system for other reasons. It may be undesirable to ever migrate data, since it may be archived or there may be a desire to always store the objects in their original form. With Objectivity/DB , this is not only possible, it’s a natural capability of Objectivity/DB ’s architecture.