我正在阅读有关时间数据库的信息,似乎它们已经建立在时间方面。我想知道为什么我们需要这样的模型?
它与普通的 RDBMS 有何不同?难道我们不能有一个普通的数据库,即 RDBMS,并说有一个触发器,它将时间戳与发生的每个事务相关联吗?可能会对性能造成影响。但我仍然对在市场上有强大案例的时间数据库持怀疑态度。
目前的任何数据库都支持这样的功能吗?
我正在阅读有关时间数据库的信息,似乎它们已经建立在时间方面。我想知道为什么我们需要这样的模型?
它与普通的 RDBMS 有何不同?难道我们不能有一个普通的数据库,即 RDBMS,并说有一个触发器,它将时间戳与发生的每个事务相关联吗?可能会对性能造成影响。但我仍然对在市场上有强大案例的时间数据库持怀疑态度。
目前的任何数据库都支持这样的功能吗?
考虑您的约会/日记 - 它从 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 不应该为同一个元组重叠。
时态数据库有效地存储数据的时间序列,通常具有一些固定的时间尺度(例如秒甚至毫秒),然后仅存储测量数据中的变化。RDBMS 中的时间戳是每次测量的离散存储值,效率非常低。时态数据库通常用于 SCADA 等实时监控应用程序中。一个完善的系统是 OSISoft ( http://www.osisoft.com/ ) 的 PI 数据库。
据我了解(并且过度简化),时间数据库记录有关数据何时有效以及数据本身的事实,并允许您查询时间方面。您最终会处理“有效时间”和“交易时间”表,或涉及“有效时间”和“交易时间”方面的“双时态表”。您应该考虑阅读以下两本书中的任何一本:
时态数据库通常用于金融服务行业。一个原因是您很少(如果曾经)被允许删除任何数据,因此记录上的 ValidFrom - ValidTo 类型字段用于提供记录何时正确的指示。
除了“我可以用它做什么新东西”之外,考虑“它统一了哪些旧东西?”可能会很有用。时态数据库代表“普通”SQL 数据库的一种特殊概括。因此,它可能会为您提供一个统一的解决方案来解决以前看起来不相关的问题。例如:
另一方面,时间模型本身是完成版本控制的一半,这可能会激发进一步的应用。例如,假设您在 SQL 之上滚动您自己的时间工具并允许分支,就像在修订控制系统中一样。即使是有限的分支也可以很容易地提供“沙盒”——一种随意使用和修改数据库而不会对其他用户造成任何可见更改的能力。这使得在复杂数据库上提供高度逼真的用户培训变得容易。
使用简单合并工具的简单分支也可以简化一些常见的工作流问题。例如,非营利组织可能有志愿者或低薪工人进行数据输入。为每个工作人员提供自己的分支可以让主管在将其合并到“普通”用户可以看到的主分支之前轻松地审查他们的工作或对其进行增强(例如,去重)。分支机构还可以简化权限。如果用户只被授予使用/查看其独特分支的权限,您不必担心防止所有可能的不必要修改;无论如何,您只会合并有意义的更改。
除了阅读维基百科的文章?维护“审计日志”或类似事务日志的数据库将具有一些“临时”属性。如果您需要回答有关谁对谁做了什么以及何时做的问题,那么您就有了一个很好的时态数据库候选人。
您可以想象一个简单的时态数据库,它每隔几秒就记录一次您的 GPS 位置。压缩这些数据的机会很大,一个普通的数据库你需要为每一行存储一个时间戳。如果您需要大量的吞吐量,知道数据是临时的并且永远不需要更新和删除一行,那么程序就可以减少典型 RDBMS 中继承的大量复杂性。
尽管如此,时态数据通常只存储在普通的 RDBMS 中。例如,PostgreSQL 有一些时间扩展,这使得这更容易一些。
想到两个原因:
只是一个更新,时态数据库即将进入 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)版本,您可以使用它。
查看此视频,了解如何在 SQL Server 2016 中使用临时表。
我对时间数据库的理解是用于存储某些类型的时间信息。您可以使用标准 RDBMS 进行模拟,但是通过使用支持它的数据库,您可以为许多概念提供内置的惯用语,并且查询语言可能会针对此类查询进行优化。
对我来说,这有点像使用特定于 GIS 的数据库而不是 RDBMS。虽然您可以在普通的 RDBMS 中推送坐标,但拥有适当的表示(例如,通过网格文件)可能会更快,并且拥有诸如拓扑之类的 SQL 原语很有用。
有学术数据库和一些商业数据库。Timecenter 有一些链接。
时态数据库有用的另一个例子是数据随时间变化的地方。我在一家电力零售商工作了几年,我们在那里存储了 30 分钟的电表读数。这些仪表读数可以随时修改,但我们仍然需要能够回顾读数的变化历史。
因此,我们有最新的读数(我们对 30 分钟消耗的“当前理解”),但可以回顾我们对消耗的历史理解。当您拥有可以以这种方式调整的数据时,时态数据库可以正常工作。
(话虽如此,我们用 SQL 手工雕刻了它,但那是很久以前的事了。这些天不会做出那个决定。)