为什么我们需要时态数据库？

Question

我正在阅读有关时态数据库的内容，似乎它们已经建立了时间方面。我想知道为什么我们需要这样的模型？

它与普通的RDBMS有何不同？我们不能拥有一个普通的数据库，即RDBMS，并且说有一个触发器，它将时间戳与发生的每个事务相关联吗？可能会有性能损失。但我仍然对在市场上具有强大案例的时态数据库持怀疑态度。

目前的任何数据库是否都支持这样的功能？

Answer 1

考虑你的预约日记日记 - 从1月1日到12月31日。现在我们可以在任何一天查询日记中的约会/日记条目。此排序称为有效时间。但是，通常不会按顺序插入约会/条目。

假设我想知道4月4日我日记里的约会/参赛作品。也就是说，4月4日我日记中存在的所有记录。这是交易时间。

鉴于可以创建和删除约会/条目等。典型记录具有覆盖条目期间的开始和结束有效时间以及表示条目出现在期间的开始和结束交易时间。日记。

当日记可能经历历史修订时，这种安排是必要的。假设在4月5日我意识到我在2月14日的约会实际上发生在2月12日，即我在我的日记中发现错误 - 我可以纠正错误，以便更正有效的时间图片，但现在，我的查询是什么在4月4日的日记中是错误的，除非，约会，条目的交易时间也被存储。在那种情况下，如果我在4月4日查询我的日记，它将在2月14日显示约会，但如果我在4月6日查询它将在2月12日显示。

时间数据库的这种时间旅行功能可以记录有关如何在数据库中纠正错误的信息。这对于记录何时进行修订的数据的真实审计图片是必要的，并且允许关于如何修改数据的查询 时间。

大多数商业信息应该存储在这个双时态方案中，以便提供真实的审计记录并最大化商业智能 - 因此需要在关系数据库中提供支持。请注意，每个数据项在二维时间模型中占据（可能无界）方格，这就是人们经常使用GIST索引来实现双时态索引的原因。这里的问题是GIST索引真的是为地理数据设计的，而时态数据的要求也有所不同。

PostgreSQL 9.0排除约束应提供组织时态数据的新方法，例如事务和有效时间PERIOD不应该重叠相同的元组。

Answer 2

时态数据库通常通过具有一些固定的时间标度（例如秒或甚至毫秒）来有效地存储数据的时间序列，然后仅存储测量数据中的变化。 RDBMS中的时间戳是每次测量的离散存储值，这是非常低效的。时态数据库通常用于SCADA等实时监控应用程序。一个完善的系统是OSISoft的PI数据库（http://www.osisoft.com/）。

Answer 3

据我所知（并且过度简化），时态数据库记录有关数据何时有效以及数据本身的事实，并允许您查询时间方面。您最终会处理“有效时间”和“交易时间”表，或涉及“有效时间”和“交易时间”方面的“双时表”。你应该考虑阅读这两本书中的任何一本：

• Darwen，Date和Lorentzos“Temporal Data and the Relational Model”（已绝版），
• 和（在完全不同的极端）“Developing Time-Oriented Database Applications in SQL”，Richard T.Snodgrass，Morgan Kaufmann Publishers，Inc.，San Francisco，July，1999,504 + xxiii pages，ISBN 1-55860-436- 7。已经绝版，但在cs.arizona.edu的网站上以PDF格式提供（因此谷歌搜索很容易找到）。

Answer 4

时态数据库通常用于金融服务行业。一个原因是很少（如果有的话）允许删除任何数据，因此记录上的ValidFrom - ValidTo类型字段用于指示记录何时正确。

Answer 5

除了阅读Wikipedia article之外？维护“审计日志”或类似事务日志的数据库将具有“暂时”的一些属性。如果您需要回答有关谁做了什么以及何时的问题的答案，那么您就有了一个很好的时态数据库候选人。

Answer 6

您可以想象一个简单的时态数据库，它每隔几秒就会记录您的GPS位置。压缩这些数据的机会很大，一个普通的数据库，你需要为每一行存储一个时间戳。如果您需要大量的吞吐量，那么知道数据是暂时的，并且永远不需要更新和删除行允许程序在典型的RDBMS中丢弃大量的复杂性。

尽管如此，时态数据通常只存储在普通的RDBMS中。例如，PostgreSQL有一些temporal extensions，这使得这更容易。

Answer 7

有两个原因浮现在脑海中：

1. 有些针对插入和只读进行了优化，可以提供显着的性能提升
2. 有些人比传统的SQL更了解时间 - 允许按秒，分钟，小时等分组操作

Answer 8

只是更新，Temporal数据库即将推出SQL Server 2016。

清除所有疑问，为什么需要一个时态数据库，而不是使用自定义方法进行配置，以及如何有效地和无缝地SQL Server为您配置，请在此处查看有关Channel9.msdn的深入视频和演示：https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

MSDN链接：https://msdn.microsoft.com/en-us/library/dn935015(v=sql.130).aspx

目前，使用SQL Server 2016的CTP2（beta 2）版本，您可以使用它。

检查this video如何在SQL Server 2016中使用临时表。

Answer 9

除了＆＃34;我可以用它做什么新的事情＆＃34;，考虑＆＃34;什么旧事物统一起来可能是有用的？＆＃34;。时态数据库代表了＆＃34; normal＆＃34;的特定概括。 SQL数据库。因此，它可以为您提供以前看似无关的问题的统一解决方案。例如：

• Web并发当您的数据库具有允许多个用户执行标准创建/更新/删除（CRUD）修改的Web UI时，您必须面对concurrent web changes problem。基本上，您需要检查传入的数据修改是否不影响自该用户上次查看这些记录以来已更改的任何记录。但是如果你有一个时态数据库，它很可能已经关联了类似于＆＃34;修订版ID＆＃34;每条记录（由于难以使时间戳独特且单调上升）。如果是这样，那就变成了自然的，已经内置的＆＃34;防止其他用户遭受破坏的机制＆＃39;数据库更新期间的数据。
• 法律/税务记录法律制度（包括税收）比大多数程序员更重视历史数据。因此，您经常会发现advice关于发票的模式，并警告您要注意删除记录或以自然方式进行规范化 - 这可能导致无法回答基本的法律问题，例如＆＃34;忘记他们目前的地址，你在2001年寄出这张发票的地址是什么？＆＃34;有了时间框架基础，那些问题的所有机制（它们通常是拥有时态数据库的一半）都会消失。您只需使用最自然的架构，并在有意义时删除，知道您可以随时返回并准确回答历史问题。

另一方面，时态模型本身就是完成修订控制的一半，这可以激发进一步的应用。例如，假设您在SQL之上滚动自己的临时工具并允许分支，就像在版本控制系统中一样。即使是有限的分支也可以轻松提供沙盒和＃34; - 放弃使用和修改数据库而不会对其他用户造成任何可见更改的能力。这使得在复杂数据库上提供高度真实的用户培训变得容易。

使用简单的合并工具进行简单分支也可以简化一些常见的工作流问题。例如，非营利组织可能有志愿者或低薪工人进行数据输入。为每个工作人员提供他们自己的分支可以让主管很容易地审查他们的工作或加强它（例如，重复数据删除），然后将其合并到主分支中，在那里它可以看到正常的＆＃34;用户。分支还可以简化权限。如果用户仅被授予使用/查看其独特分支的权限，则您不必担心会阻止所有可能的不必要的修改;你只会合并有意义的变化。

Answer 10

我对时态数据库的理解是为了存储某些类型的时间信息。您可以使用标准RDBMS来模拟它，但是通过使用支持它的数据库，您可以使用许多概念的内置习惯用法，并且可以针对这些类型的查询优化查询语言。

对我而言，这有点像使用特定于GIS的数据库而不是RDBMS。虽然你可以在一般的RDBMS中推动坐标，但是具有适当的表示（例如，通过网格文件）可能更快，并且具有拓扑之类的SQL原语是有用的。

有学术数据库和一些商业数据库。 Timecenter有一些链接。

Answer 11

时态数据库有用的另一个例子是数据随时间变化的地方。我花了几年时间在一家电力零售商工作，在那里我们存储了30分钟的电表读数。这些仪表读数可以在任何时候修改，但我们仍然需要能够回顾读数的变化历史。

因此，我们有最新的阅读（我们对30分钟消费的“当前理解”），但可以回顾我们对消费的历史性理解。当您获得可以通过这种方式调整的数据时，时态数据库可以很好地工作。

（话虽如此，我们用SQL手工雕刻它，但它在很久以前就是公平的。这些天不会做出那个决定。）