Browse Prior Art Database

A new method for temporal table storage design

IP.com Disclosure Number: IPCOM000245717D
Publication Date: 2016-Apr-01
Document File: 4 page(s) / 211K

Publishing Venue

The IP.com Prior Art Database

Abstract

Temporal tables(or temporal database) introduces the concept of a table being defined with temporal attributes. A system time period is a system maintained period in which database will keep track of when a row is created and when a row is deleted from a table. For each row is updated during the transaction, the current active rows is stored in current table, and the whole old row(be updated) is stored in history table. We can use time travel query to query history data. As time goes on, there will be more and more history data, the history table become very huge, and the storage is one of the major concern for big customer, which prevent them to adopt our temporal solution. In our solution, we introduce different tablespaces to store different column groups in history table, one for the columns be updated frequently, we call history table spase, one for the rest of columns that rarely be updated, we call auxiliary table space, and there will be a link between history table spase and auxiliary table spase.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 4

A new method for temporal table storage design

Temporal tables(or temporal database) introduces the concept of a table being defined with temporal attributes. A system time period is a system maintained period in which database will keep track of when a row is created and when a row is deleted from a table. For each row is updated during the transaction, the current active rows is stored in current table, and the whole old row(be updated) is stored in history table. We can use time travel query to query history data.

As time goes on, there will be more and more history data, the history table become very huge, and the storage is one of the major concern for big customer, which prevent them to adopt our temporal solution.

In our solution, we introduce different table spaces to store different column groups in history table, one for the columns be updated frequently, we call history table spase, one for the rest of columns that rarely be updated, we call auxiliary table spase, and there will be a link between history table spase and auxiliary table spase. When updating a row, most likely we only need store the incremental part of data in history table spase, and we don't need store additional data for the no-updated part in auxiliary table spase, the no-updated data can be shared between different version of rows. When retrieve a row, it can link the column groups together. By this method, we could save large amount of storage, and separate a big table into two smaller table - history table and aux table, which can improve the query performance in some scenario.

In this method, we could keep the statistics information for column updated times for reference, and with these statistics, our algorithm is able to decide which columns group are updated frequently and should be kept in history table spase, and which columns are updated...