Documentation:Purpose of History Server: Difference between revisions

Purpose of History Server

Latest revision as of 15:45, 10 February 2024

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

Answering tough questions on how the data has ended up in the current state. This is frequently needed for business, support, and debugging reasons
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.

This page was edited 97 days ago on 02/10/2024. What links here

@@ Line 1: / Line 1: @@
-History views past time in the eyes of todays definition
+History views past time in the eyes of today's definition.
-History is not a history of definition - its history of data
+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).
-If new definition is applied no knowledge of this new definition is available prior to that time - and thus no data can be present prior to this point
+To keep full historic snapshots of data and definition, use database backup -  and backup retention settings.
-If new definition removes existing definition - data that complies to that definition is also removed through out time - this cause data-loss of historic data that cannot be represented in the current definition
+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.
-To keep history of definition use GIT on the model (or other repository for code/definition)
+=== Reasons For Keeping a History Database ===
+# Answering tough questions on how the data has ended up in the current state. This is frequently needed for business, support, and debugging reasons
-To keep full historic snapshots of data and definition use database backup -  and backup retention settings
+# 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.
-What MDrivenServer-History database offer is a manageable middleground to track changes to help a user understand the evolution of data in the perspective of the current definition. This is a fantastic functionality for mostly stable definitions and help users to see the dynamics of data changes.
+[[Category:MDriven Server]]
+{{Edited|July|12|2024}}
-=== Reasons for keeping a history database ===
-# Answering though questions on how data has ended up in the current state - this is frequently needed for business reasons, support reasons and for debugging reasons
-# 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 very low since all of the normal issues with historic data transformation as often is costly in CQRS-systems is automatically handled by the server (mind you with certain dataloss when you drop old definitions). The gains are very high when a need to find why data is a certain way since the keeping of a history database allows for temporal browsing that is not possible by restoring old backups - and the resolution is complete for recent events unlike in backups that only hold snapshots.