Transaction Time Tables in MSSQL and Constraints I am trying to implement transaction time tables on a MSSQL Server 2016 following the book by Richard Snodgrass (Developing Time-Oriented Database Applications in SQL).
A table with a sequenced primary key through a trigger could be implemented like this:
CREATE TABLE test_table (
a [tinyint] NOT NULL,
b [date] NOT NULL,
c [float] NOT NULL,
[tt_start] [datetime2](7) NOT NULL,
[tt_end] [datetime2](7) NOT NULL)
GO

CREATE TRIGGER Seq_Primary_Key_tt ON test_table FOR INSERT, UPDATE, DELETE AS
  BEGIN
    IF (( EXISTS ( SELECT * FROM test_table AS b1
    WHERE 1 &lt; (SELECT COUNT(b2.a) FROM
        test_table AS b2
        WHERE b1.a = b2.a AND
        b1.b = b2.b AND
        b1.tt_start &lt; b2.tt_end AND b2.tt_start &lt; b1.tt_end) )))
    BEGIN
        RAISERROR('Transaction violates sequenced constraint', 1, 2)
        ROLLBACK TRANSACTION
    END
 END

 GO

The trigger is pretty slow on larger tables. Therefore, using multiple INSERTs leads to long waiting times. Furthermore, many operations like updates require more than one operation (e.g. INSERT, then UPDATE). This doesn't work with this trigger, because the trigger would start already after the INSERT and fail, although the operation would perfectly work out if the trigger would start after the UPDATE.
That is why Snodgrass writes that the constraints/assertions (or here the trigger) have to be DEFERRABLE INITIALLY DEFERRED. In that way, the constraints would be checked after all operations have finished. This would at the same time also increase the performance of multiple INSERTs.
However, as far as I see, MSSQL Server doesn't implement DEFERRABLE INITIALLY DEFERRED. How could a similar constraint or trigger be then implemented? Or could the &quot;temporal tables&quot; feature be a replacement for what I am trying to do?
The trigger is pretty slow on larger tables.

You don't have any indexes, and you aren't limiting the check to the rows affected by the statement using the INSERTED virtual table.  See: Use the inserted and deleted tables

many operations like updates require more than one operation

In scenarios like this you're better-off managing the updates through a stored procedure, rather than trying to handle everything with a trigger.  For instance if you insert an adjoining interval, you'd probably want to coalesce them.