标签: bi-temporal

在SQL中实现双时态数据库时,通常建议使用以下时间戳:

• ValidStart
• ValidEnd
• TransactionStart
• TransactionEnd

我以前曾经使用过这种方法几次,但我一直想知道为什么只有3个时间戳,将TransactionEnd保留在外,这不仅仅是一个正确的实现.这里的事务时间范围从TransactionStart到下一个TransactionStart.

是否有强大的论据不仅使用3个时间戳,这将限制数据库的大小？

在实现时间日期时间对时，哪种方法更好？

方法一

_RK   FROM_DTTM              TO_DTTM 
1     01-JAN-2012 00:00:00   31-DEC-2012 23:59:59 ------------> Old record closed out 
1     01-JAN-2013 00:00:00   31-DEC-4949 23:59:59 ------------> New active record

与过滤子句一起使用，如下所示：

 where FROM_DTTM <= &FILTER_DATE <= TO_DTTM

方法2

_RK   FROM_DTTM              TO_DTTM 
1     01-JAN-2012 00:00:00   01-JAN-2013 00:00:00 ------------> Old record closed out 
1     01-JAN-2013 00:00:00   31-DEC-4949 23:59:59 ------------> New active record

与过滤子句一起使用，如下所示：

 where FROM_DTTM <= &FILTER_DATE < TO_DTTM

注意事项：

方法 1 与 BETWEEN 子句语法（包含范围）兼容。出于这个原因，我认为这是最好的方法，但是 - 这是我担心的 - 关闭和打开时间戳之间总是存在差距！例如，以下内容（从业务角度来看是错误的）不会返回任何内容：

 where FROM_DTTM <= '31-DEC-2012 23:59:59.1'dt <= TO_DTTM

不同的数据库在这里会有不同的精度级别。我想必须有一个标准（过滤时总是四舍五入到最接近的秒），但只是想知道是否还有其他原因支持方法 1（例如建议的双时态“AS …

我正在尝试收集有关时态数据库的信息。我知道这不是一项现代技术，但我看到许多使用数据库的人都不知道时态方法是如何工作的（我向一些高级程序员和系统分析师询问了时态数据库，他们的回答类似于“嗯？”） 。

我知道有有效时间状态表和事务时间状态表，以及双时态表。我认为双时态表对于大多数用途来说都太复杂了，因为现在空间不再是问题，而且即使数据是冗余的，在两个不同的表上写入相同的信息会更有效。然而，我在网上做了很多搜索，试图了解双时态表的实际使用情况，但没有找到任何有用的东西。

是否存在使用双时态表确实比分别使用有效时间和事务时间状态表更方便的情况？有现实世界的例子吗？

我遇到了时态函数“ temporal.documentDelete ”，它“逻辑删除”MarkLogic 数据库中的时态文档，从而将其从最新集合中删除。但该文档仍未从 MarkLogic 数据库中物理删除。您仍然可以使用其 URI 检索已删除的文档。

有没有什么办法，我也可以物理删除摄取到我的 MarkLogic 数据库中的临时文档？