如果你在事后发现一个事实，你如何 Datomic？答案

【问题标题】：If you discover a fact after the fact, how do you Datomic?如果你在事后发现一个事实，你如何 Datomic？
【发布时间】：2017-02-02 23:23:13
【问题描述】：

我对 EAVT 的理解是，当事实被插入 Datomic 时，T 必须是。通常在我的工作中，事实可以在它们发生几个月后被插入到系统中。显然，我可以在我的模式中添加一个“at”属性，但这似乎破坏了 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 的整个历史记录，并遍历一个自定义的 at 字段。或者进行某种二进制 asof 搜索。看起来都不是很吸引人。

【问题讨论】：

您在更新中表达问题的方式似乎将系统时间（t 值）和事件时间混为一谈。说t=1: I receive a fact that at '2016-09-26T00:00:00Z' x=5更准确吗？在这种情况下，问题将是“2016-09-27:00:00:00Z 的 x 是什么？”。
是否准确地说您的问题更多是关于有效访问历史属性而不是在哪里存储日期时间？我想我明白你在追求什么。如果系统时间和事件时间相同，可以使用as-of直接访问相应的db。否则，您必须四处寻找合适的数据库。对于我的用例来说，查询历史从来没有特别慢过。这些属性会有很多历史吗？
是的，这就是难题。 :) 在特定情况下，我认为属性往往每 2 天更改一次，历史长达 2 年。在 SQL 数据库中，我可能会记录按事件时间索引的每个更改的记录，这应该允许我有效地找到当时的活动记录。但是除了完整的历史扫描之外，我想不出在 Datomic 中这样做的方法。完整的历史扫描可能很好，但如果有更好的模式来处理这个难题，我很感兴趣。

标签： datomic

【解决方案1】：

蒂姆·波特是正确的。域时间（在“现实世界”中发生的事情）和系统时间（当 Datomic 发现它时）之间的区别是一个重要的区别，当域时间可能与系统时间不同时，明确地建模域时间绝对是一种好方法.

【讨论】：

我的问题是关于在特定时间有效地找到事实的价值。有没有办法做到这一点？
所有 Datomic 数据库，包括 asof 数据库，都提供多个跨越索引。针对 asof 数据库的查询将使用索引来有效地解析查询。
嗨马歇尔；谢谢 - 我感谢您的意见。我看不到快速的asof 查询对我的场景有什么帮助。重申一下，我正在寻找一个时间由域时间定义的事实，所以我必须检查value。但是对于任何给定的数据库，只有 1 个值。所以我能想到的唯一查询是“给我在我认为事实可能已经被摄取的时间范围内的所有历史价值”。在我面临的情况下，时间框架的问题可能很大。

【解决方案2】：

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

我唯一避免添加日期属性的情况是，“系统何时知道”和“何时发生”是相同的定义。例如，“用户何时创建此待办事项”可以定义为待办事项进入数据库时的:db/txInstant。

【讨论】：

在我的情况下，这个事实稍后会为人所知。我添加了一个更具体的案例，说明为什么“at”方法感觉不正确。也许我只是缺少正确的方法来查询在事实之后必然发生摄取的时间点（这是由于第 3 方数据提供者而发生的）。