Historical versions

These historical snapshots of the database are based on change events. A change event is any database action that moves the database from one state to another, adding a new feature, dropping a table, or modifying an attribute are all examples of change events. The temporal granularity of a geodatabase, or the frequency of modifications made to the database, is determined by how often these change events occur and are recorded.

In a geodatabase, changes to the database can occur as a result of a long transaction, a collection of individual database actions, or short transactions. The frequency of recording these transactions will be determined by the individual requirements of each organization or application. For some, every change to the database must be preserved in a historical record; for others, a less frequent archiving regime will suffice.

Some of the typical historical queries that a versioned geodatabase may have to support include:

• What was the state of the database at a given time? How frequently historical versions are captured will determine how accurate the information returned by these queries will be.
   
• How has a particular feature changed over time? This is generally referred to as a lineage search. As with the previous query, the level of information that will be returned by the query will be determined by how frequently historical records were captured.
   
• Given that an object or feature was removed from the database at a certain date, what features currently exist where the deleted feature used to be? This type of query forms the basis of a comparison between historical and current feature configurations.

A common requirement for maintaining a historical record is to preserve an archive of the DEFAULT version, although historical versions can be created from any version. As an example, to preserve a record of a project at any stage in the project life cycle, a new historical version could be created from the project version itself. When the project version is reconciled and posted to its parent version, the project archive would remain as a record of the project at a particular stage.

Pros

• As with any other version, when the historical version is captured, all aspects of the data model at that point in time are recorded, including network connectivity, relationships, topology errors, and so on.
• No additional data modeling or application customization is required to support historical versions; this functionality is intrinsic to the versioning model.

Cons

• This version configuration may affect performance in the long term. As with the other, more complex version structures, the more information that is maintained in the delta tables, the longer each version difference query will take. To maintain a good level of performance in the geodatabase, at some point in the future, this historical information should be archived offline.

Geodatabase archives

Geodatabase archiving stores information about changes to data in a separate table. When archiving is enabled on a versioned dataset, an archive table is created. When archiving is enabled, all attributes and all rows in the DEFAULT version of the dataset are copied to the archive class; therefore, the archive class has the same schema as the original dataset. Additionally, it has date attributes, gdb_from_date and gdb_to_date, to record the timestamp for the effective lifespan of the archived row and a gdb_archive_oid attribute to uniquely identify each row.

See the “Archiving data” section of the ArcGIS Desktop or Server help for more background information plus instructions on how to use geodatabase archiving.