We are rebuilding the functionality of a mainframe application on client/server application with relational database.
The mainframe application provided 'history' functionality on the majority of it's screens. 'History' brought the user back to the previous version of the data and highlighted the fields which differed between previous and
current data. The timestamp of the change to the data was displayed. This was quite simple as all of the data displayed on the screen was stored in one place on the mainframe database with a single timestamp associated with
all of the data.
We need to provide similar 'history' functionality in the client / server application. However, the relational data model does not hold all data for each screen on a single table. Each table has it's own timestamp. (Each
table also has an equivalent history table which stores history records.)
This raises the question: what is the best way to present history to users when there is more than one data source and more that one timestamp relevant to the data on screen?
In some cases, we could force all tables represented on a particular screen to have the same timestamp by updating all tables relevant to the screen at the same time even if data has not actually changed on all tables. I have
a concern about the volume of history data this will generate.
I need to define an approach for the presentation of 'history' to users. Has anyone faced this issue? How did you present history information in such circumstances?
------
Dublin, Ireland.
The mainframe application provided 'history' functionality on the majority of it's screens. 'History' brought the user back to the previous version of the data and highlighted the fields which differed between previous and
current data. The timestamp of the change to the data was displayed. This was quite simple as all of the data displayed on the screen was stored in one place on the mainframe database with a single timestamp associated with
all of the data.
We need to provide similar 'history' functionality in the client / server application. However, the relational data model does not hold all data for each screen on a single table. Each table has it's own timestamp. (Each
table also has an equivalent history table which stores history records.)
This raises the question: what is the best way to present history to users when there is more than one data source and more that one timestamp relevant to the data on screen?
In some cases, we could force all tables represented on a particular screen to have the same timestamp by updating all tables relevant to the screen at the same time even if data has not actually changed on all tables. I have
a concern about the volume of history data this will generate.
I need to define an approach for the presentation of 'history' to users. Has anyone faced this issue? How did you present history information in such circumstances?
------
Dublin, Ireland.