Temporal Tables in SQL Server and Azure SQL Database

In this article, we will be discussing about Temporal Tables in SQL Server and Azure SQL Database.

Temporal tables in SQL Server 2016 and later as well as in Azure SQL Database is a new type of user table which was was introduced in ISO/ANSI SQL 2011. Read on to learn more temporal tables and see a comprehensive example that uses them.

Temporal tables keep a full history of data changes (based on UTC time) by using a pair of current-historical tables. These tables has the same structure.

The period of validity for every row is managed by the system (i.e. Database Engine) by using two explicitly-defined columns of the DateTime2 datatype.

Example with Temporal Tables (T-SQL)

Below you can find an example of a user table’s definition that has system versioning enabled:

--Create table along with specifying its historical table
CREATE TABLE dbo.Students2
(
  studentID INT NOT NULL IDENTITY(1,1) CONSTRAINT PK_Students PRIMARY KEY,
  studentName VARCHAR(150) NOT NULL,
  studentAddress VARCHAR(150) NOT NULL,
  regDate DATE NOT NULL,
  SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
  SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
  PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Students2History));
GO

The above DDL will create two tables: (i) Students2, and (ii) Students2History.

In the “dbo.Students2” table, the user needs to populate only the first 4 columns (studentID, studentName, studentAddress and regDate). Note: In this case “studentID” will be populated automatically too because it is an identity column. The rest of the columns will be maintained automatically by SQL Server’s Database Engine. Table “dbo.Students2History” will be populated fully automatically by the Database Engine.

In the below screenshot we can see both tables:

Let’s check both tables for any contents:

Now, let’s insert some data in the “dbo.Students2” table:

--Insert initial data
INSERT INTO dbo.Students2
        ( studentName ,
          studentAddress ,
          regDate 
        )
VALUES  ( 'John Adams', 
          'Address 1', 
          GETDATE() 
        );
GO

Let’s check again both tables for any contents:

As you can see, the “dbo.Students2” table was populated with data.

The “dbo.Students2History” table was not populated with any data because system versioning works only in case of an update operation against one or more rows.

That being said, let’s try to update the row:

--Now let's update a record
UPDATE dbo.Students2
SET studentAddress='Address 1 Update'
WHERE studentID=1;
GO

Let’s check again the table contents:

Now you can see that the table “Students2History” contains the original values for row with studentID=1 just before the update operation took place.

Let’s update the same record again:

--Update the same record
UPDATE dbo.Students2
SET studentAddress='Address 1 Update 2'
WHERE studentID=1;
GO

Let’s check the table contents:

As you can see, the table “Students2History” contains also the “new” original value for row with studentID=1 just before the new update operation took place. So in total, the historical table contains the rows for studentID=1 just before the two update operations took place. The validity of each row can be determined from the “SysStartTime” and “SysEndTime” values.

Conclusion

• Auditing all data changes (i.e. for data forensics)
• Data reconstruction/recovery
• Trends monitoring over time

Check Also:

• SQL Server 2016 Top Features
• The set identity_insert Command in SQL Server
• The Import Flat File Wizard in SSMS v17.3
• Listing all Tables of a Linked Server’s Database
• How to Import and Export Unstructured Data in SQL Server – FileTables
• How to Import and Export Unstructured Data in SQL Server – FILESTREAM
• How to Import and Export Unstructured Data in SQL Server – The IMAGE Datatype
• …more