History views past time in the eyes of today's definition.

History is not a history of definition - it is a history of data.

• If a new definition is applied, no knowledge of this new definition is available before that time - thus, no data can be present before this point.
• If a new definition removes the existing definition, data that is compliant with that definition is also removed over time. This causes the data loss of historic data that cannot be represented in the current definition.

To keep a history of definition, use GIT on the model (or another repository for code/definition).

To keep full historic snapshots of data and definition, use database backup -  and backup retention settings.

What the MDrivenServer History database offers is a manageable middle-ground to track changes and help a user understand the evolution of data from the perspective of the current definition. This is a fantastic functionality for mostly stable definitions and helps users see the dynamics of data changes.

Reasons For Keeping a History Database

1. Answering tough questions on how the data has ended up in the current state. This is frequently needed for business, support, and debugging reasons
2. Research into data change - how often has data changed historically? How does data grow over time?

The cost of ownership of an MDrivenServer History database is low since all of the normal issues with historic data transformation are often costly. In CQRS systems, it is automatically handled by the server (mind you, with some data loss when you drop old definitions). The gains are very high when a need to find why data is a certain way arises since keeping a history database allows for temporal browsing that is impossible by restoring old backups - and the resolution is complete for recent events, unlike in backups that only hold snapshots.