问题标签 [temporal-database]

我有（为示例简化）一个包含以下数据的表

日期代表一个时间段，ID 是系统在该时间段内所处的状态，而金额是与该状态相关的值。

我想要做的是聚合具有相同ID 号的相邻行的数量，但保持相同的整体顺序，以便可以组合连续的运行。因此，我想得到如下数据：

我追求可以放入 SP 的 T-SQL 解决方案，但是我看不到如何通过简单的查询来做到这一点。我怀疑它可能需要某种迭代，但我不想走那条路。

我想要进行此聚合的原因是该过程的下一步是执行按序列中出现的唯一 ID 分组的 SUM() 和 Count()，这样我的最终数据将类似于：

但是，如果我做一个简单的

在原来的桌子上，我得到了类似的东西

这不是我想要的。

您将如何表示 SQL 中的时间多对多关系？在非临时情况下，可以使用连接表（又名链接/桥梁/地图）来连接两侧。

添加时间跟踪是否像在联结表上包含 ValidStart 和 ValidEnd 列一样简单？如果你这样做了，你遇到了什么问题（如果有的话）？有没有更好的方法来跟踪这种关系随时间的变化？

如果它有帮助，在我的情况下，我专门使用 SQL 2008 并且时间数据不是双时间的，因为我只跟踪有效时间。

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

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

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

在你遇到菲尔丁和他的论文之前，不需要太多关于 REST 的阅读

如果您在关系存储范围内的时间建模方面取得了一些胜利 您提到的领域中有哪些知名人士？

我们使用第三方产品来管理我们的体育中心会员资格。我们有多种会员类型（例如初级、学生、员工、社区）和多种会员状态（例如年度、活跃、非活跃、暂停）。不幸的是，该产品仅记录会员当前的会员类型和状态。我希望能够跟踪我们成员的类型和状态随时间变化的方式。

目前，我们已经接触到了产品的数据库设计。它在 SQL Server 上运行，我们定期对产品的表运行我们自己的 SQL 查询以生成我们自己的表。然后，我们将表格链接到 Excel 中的数据透视表以生成图表。所以我们熟悉数据库设计和SQL。然而，我们被困在如何最好地解决这个问题上。

该产品记录会员的会员购买及其开始和到期日期。因此，我们可以通过该数据进行回溯，以确定成员在任何时间点的类型和状态。例如，如果他们在 2007 年 1 月 1 日购买了初级会员，并在 2007 年 12 月 31 日到期，然后他们在 2008 年 6 月 1 日购买了学生会员，我们可以看到他们的状态从活跃到不活跃再到活跃（1 月2008 年 1 月 1 日和 2008 年 6 月 1 日），他们的类型从初级到学生（2008 年 6 月 1 日）。

本质上，我们希望将成员的类型和状态属性转换为时间属性或有效性a-la Fowler（或其他随时间变化的东西）。

我们的问题（最后:) - 鉴于上述情况：您建议我们使用哪种数据库表设计来保存此成员信息。我想它会有一个 MemberID 列，所以我们可以键入现有的 Member 表。它还需要存储成员的状态和类型以及他们被保留的日期范围。我们希望能够轻松地针对此表编写查询，以确定在给定时间点我们拥有的每种类型和状态的成员数量。

2009 年 8 月 25 日更新：已被搁置，还没有机会尝试提出的解决方案。希望尽快这样做，并将根据结果选择答案。

时态数据库的日期应该存储在一个或两个表中吗？如果这不违反规范化？

DATE1 和 DATE2 列指示 INFO1 和 INFO2 在 DATE1 和 DATE2 之间的时间段内为真。如果 DATE < TODAY，则事实已被弃用，不应再在用户界面中显示，但不应出于历史目的而将其删除。例如，现在不推荐使用 INFO11 和 INFO21。

我应该拆分这张桌子吗？我应该将状态（已弃用或当前）存储在表中吗？

为了进一步澄清这个问题，Deprecated 是业务使用的术语，如果您更喜欢“不是当前”，问题不是语义，也不是关于 sql 查询，我只想知道哪种设计违反或最适合规范化规则（我知道标准化并不总是可行的方法，这也不是我的问题）。

我需要以易于索引的方式存储实体的所有版本，并且想知道是否有人输入了要使用的系统。

如果没有版本控制，系统只是一个关系数据库，每个人都有一行。如果此人的状态发生变化，则该行将更改以反映这一点。使用版本控制，条目应该以这样的方式更新，以便我们总是可以回到以前的版本。如果我可以使用时态数据库，这将是免费的，我将能够询问“截至昨天下午 2 点住在都柏林且 30 岁的所有人的状态如何”。不幸的是，似乎没有任何成熟的开源项目可以做临时性的。

一个非常讨厌的方法是在每次状态更改时插入一个新行。这会导致重复，因为一个人可以有许多字段，但每次更新只能更改一个。然后为给定时间戳的每个人选择正确的版本也很慢。

理论上应该可以使用关系数据库和版本控制系统来模拟时间数据库，但这听起来很可怕。

所以我想知道是否有人以前遇到过类似的事情以及他们是如何解决的？

更新 正如 Aaron 所建议的，这是我们目前使用的查询（在 mysql 中）。超过 200k 行的表在我们的表上肯定很慢。（id = 表键，person_id = 每个人的 id，如果这个人有很多修订，则重复）

从人员 p 中选择姓名，其中 p.id =（从人员中选择 max(id)，其中人员 ID = p.person_id 和时间戳 <= :timestamp）

更新 看起来最好的方法是使用临时数据库，但鉴于没有任何开源数据库，下一个最佳方法是每次更新存储一个新行。唯一的问题是重复未更改的列和缓慢的查询。

I'm exploring options for implementing a large-scale temporal database. There will likely be billions of records managed with minimal temporal churn, and I'd like a vendor implemented solution to avoid placing too much responsibility in the application(s) that will populate, update, and query the warehouse.

Oracle Workspace Manager is one potential solution I'm looking at, but I've gotten the impression from online research that OWM isn't practical for a production system. Does anyone have any experience with using OWM for a temporal database, in particular using the TSQL2 constructs?

Many thanks.

我正在建立一个网站。它有用户可以加入的组。

此组与“正常”组之间的区别在于成员资格是临时的 - 当用户加入组时，他决定成员资格的长度：5 天、一周、2 周等（选择是预定义的）。或者可能所有的会员资格都可以设置为相同的长度——比如一周——如果这样可以让事情变得更简单。

我想对每个组的成员数量进行统计。该数字不需要精确到最后一秒。但它也不能太过时——比如说，应该每天更新一次。

计算成员数量的“明显”方法似乎是运行一项 cron 作业，例如每天，并逐个检查每个组的每个成员。如果成员资格已过期，请将该成员从组中删除，并将组的成员计数减 1。

这种方法似乎非常低效且不可扩展。如果有大量的组，这可能需要很长时间。

你能想出更好的方法来做到这一点吗？成员计数不需要精确到最新的秒数。它可能是近似的并且（稍微）过时。此外，如果有所不同，所有成员资格都可以设置为相同的长度，比如一周。

我正在寻找完全基于时间概念的某种类型的 SQL 数据库，就像那些以地理为中心、以关系为中心的数据库一样。

我的主要愿望是我可以在进行过程中对数据库进行更改，然后在任何时候运行一个基本上说的查询，告诉我数据库是如何看待这个日期和时间的。我更希望 SQL 数据库内置此功能，而不必使用日志表重新实现它并记录每个事务。

我希望做一个白日梦吗？

谢谢！

编辑：经过一些进一步的研究，似乎“时间数据库”可能是我正在寻找的。因此，有关使用其中之一的任何信息，如果有任何好的开源可用信息等，将非常有帮助！