SQL Server 2016 is the first SQL Server version that has some built-in support for temporal data. However, even in SQL Server version 2017, the support is still quite basic. SQL Server 2016 and 2017 support system-versioned tables only. You have seen at the beginning of this chapter that application versioned tables, and of course bitemporal tables, add much more complexity to temporal problems. Unfortunately, in order to deal with application validity times, you need to develop your own solution, including your own implementation of all constraints, on which you need to enforce data integrity. In addition, you need to deal with the optimization of temporal queries by yourself as well.

In SQL Server 2017, you can define the retention period for historical rows. Therefore, you do not have to do the history data cleanup by yourself, like you needed to do in SQL Server 2016. Nevertheless, it would be very useful to also have the ability to define the absolute maximum number of historical rows you want to keep, and the maximum number of versions per row. This way, you could prevent a scenario where frequent updates of some rows occupy the most space in the historical table, overwhelming the history of the rows that are not updated that frequently.

If you are familiar with analytical applications and data warehouses, you might think that system-versioned temporal tables can help you in analytical scenarios. However, as you will learn in the next section, which briefly introduces data warehouses and the slowly changing dimensions problem, analytical applications have typically different granularity requests and system-versioned temporal tables don't help there.