bigblue ,azienda ,crm ,bigbluecrm ,bigbluedoc ,documentale ,as400 ,ibmi ,ibm ,bedin ,soranno ,software ,information ,bcd ,bcditalia ,ECM ,marketing ,solution ,manager ,britishairways ,topmanager ,dsi
Today I want to introduce you to an incredible news introduced by the V7R3M0 which I think few know (but tell me if it’s not true). This is the support for the Temporal database, which means that the system’s ability not only to record automatically and track the variations of the rows of a table, but also to be able to retrieve the data from that table as it was at a precise date.
With a great deal of simplification both for managing logs and audits and making track of any information without any management activity.
In a pre-730 environment, those who wanted to keep track of the changes had to go on their own by using triggers and / or saving related news items. The ability to retrieve table data at a given date was even more complex (we only think of issues related to reprinting a historical invoice when customer data may have changed, but also about confirmations Order or any other scope).
With support for the ‘time tables’ introduced with 7.3.0 all this becomes easy because it is managed by the operating system.
To use the Temporal database functions, I need to create (or add) to the table that I want to register three columns, which are formally a timestamp: The line’s validity start date, the end date of the line and the transaction number for editing. If I need to register other data for audit purposes, I can add other fields, such as the editing user, or the type of editing.
Once you’ve created the table, just use a SQL command:
CREATE TABLE hist_MyTable LIKE MyTable;
ALTER TABLE MyTable ADD VERSIONING USE HISTORY TABLE hist_MyTable ON DELETE ADD EXTRA ROW;
And magic begins!
Not only, as I said, every change in the ‘historical’ table will begin to record the ‘previous’ data completely modify, regardless of whether the source of the change is either native SQL or I / O, but any changes made to the structure Of the ‘source’ table (such as adding a column) will automatically be returned to the historical table, in addition to this, I / O SQL operations on the historical table are not allowed to ensure data integrity.
Once my structure is active, I will be able to request the ‘history’ of the line according to my needs: specifying FOR SYSTEM_TIME AS OF
(TimeStamp) to request the line with the value it had at the specified time, but also FROM / TO or BETWEEN to list all the changes made in a given time interval.
The adoption of historical tables, not very publicized, is a formidable aid to developing ever more complete databases, and once again demonstrates how IBM works to integrate more and more into complex system functions, ensuring complete integration and operation Regardless of the data updating tools used.
I do not think I’m taking sides.
If there is a more advanced system, I will be glad to adopt it.