如果事后发现事实，Datomic如何？

我对EAVT的理解是，当事实被插入到Datomic中时，T必须是。通常在我的工作中，事实可以在事件发生后的几个月内插入到系统中。很显然，我可以在我的模式中添加一个“at”属性，但这似乎打败了Datomic的大部分价值。是否有方式处理这种时间断开的模式或技术？如果事后发现事实，Datomic如何？

主要的问题我想避免的是：

t=1: I receive a fact that at t=0 x=5 
t=3: I receive a fact that at t=2 x=6 
t=5: I receive a fact that at t=4 x=7

什么是X @ T = 2.5？

要回答这个问题，我想我必须查询x的整个历史，并遍历字段的自定义。或者做一些二进制搜索。这两者似乎都不太吸引人。

来源

2016-09-25 Timothy Pratley

您在更新中短语问题的方式似乎会混淆系统时间（'t'值）和事件时间。是否更准确地说't = 1：我收到'2016-09-26T00：00：00Z'x = 5'这个事实？在这种情况下，问题将是“什么是x在2016-09-27：00：00：00Z？”。 –

准确地说，你的问题更多地是关于历史属性的有效访问，而不是存储日期时间的地方？我想我明白你在追求什么。如果系统时间和事件时间相同，则可以使用“as-of”直接访问相应的数据库。否则，你将不得不四处寻找合适的分贝。查询历史对于我的用例从未特别慢。这些属性会有很多历史吗？ –

是的，那是难题。 :)在特定情况下，我想到的属性往往每两天更改一次，历史最长可达2年。在SQL数据库中，我可能会记录事件时间索引的每个更改，这应该使我能够有效地找到当时的活动记录。但我想不出在Datomic中这样做的方法，除了完整的历史记录扫描。完整的历史记录扫描可能很好，但如果有更好的模式来处理这个难题，我很感兴趣。 –

原则上，:db/txInstant是系统已知事实的记录。如果知道的事实是“发生某些事件时”，我认为为该知识添加属性没有问题，例如， :person/birthday或:historical-event/date-time。

我唯一避免添加日期属性的时间是“什么时候该系统已知”和“何时发生”的定义是根据定义。例如，“用户何时创建该待办事项项目”可以定义为:db/txInstant，用于当待办事项项目进入数据库时。

来源

2016-09-25 18:15:48

在我的情况下，事实会在以后知道。我添加了一个更具体的案例，说明为什么“at”方法不合适。也许我只是错过了正确的方式来查询事件发生后必然发生的一个时间点（这是因为第三方数据提供者）。 –

蒂姆波特是正确的。域时间（当'现实世界'中发生的事情）和系统时间（当Datomic发现它时）之间的区别是非常重要的，明确地建模域时间当它可能与系统时间不同时。

来源

2016-09-26 13:21:12 Marshall

我的问题是关于在特定时间有效地发现事实的价值。有没有办法做到这一点？ –

所有Datomic数据库（包括asof数据库）都提供多个生成索引。针对数据库的查询将使用索引高效地解析查询。 – Marshall

嗨马歇尔;谢谢 - 我很欣赏这个输入。我没有看到在我的场景中如何快速进行“asof”查询。重申一下，我正在寻找时间由域时间定义的事实，所以我必须检查“值”。但对于任何给定的分贝，只有1个值。所以我能想到的唯一问题就是“在我认为事实可能已被摄入的时间范围之间给我所有的历史价值”。在我面临的情况下，作为时间表的问题可能会很大。 –

如果事后发现事实，Datomic如何？

回答

相关问题