问题标签 [temporal-tables]

未能找到令人满意的解决方案，让我在这里发布：

我们使用 NHibernate 作为我们的 ORM，并且刚刚开始使用 Sql Server 时态表。因此，我们需要对 IQueryable（或 HQL Builder 或 InterceptingProvider 或其他东西）进行某种扩展，以允许我们将“AS OF”子句添加到我们的查询中，例如

我们正在公司中构建一个系统，该系统将需要 sql server 中的临时表，并且可能还需要日志传送。我想知道日志传送对临时表是否会产生任何在普通表上不会发生的意外影响？

我想迁移或编写一个等效的查询，以便在 PostgreSQL 中的当前时间前一小时从表中获取数据。

甲骨文查询：

我有一个 SQL Server 2017 数据库，并创建了一个Department表，如下所示

接下来我使用下面的代码插入了一行

Department我在表格和DepartmentHistory表格上运行了一个选择，Department包含我插入但DepartmentHistory没有插入的 1 行。

我运行如下更新，发布更新，其中DepartmentHistory填充了 1 行。

时态表不显示插入的行吗？

我们正在考虑为我们的一些表实现双时间解决方案，因为它们必须记录应用程序时间和系统时间。

我知道 SQL 2016 仅对系统时间组件具有原生支持，因此我们会将表转换为临时表并修改我们现在拥有的内容以创建功能齐全的双时间解决方案。

我的问题是关于一致性。时态表的系统时间结束日期组件设置为 9999-12-31 23:59:59.9999999，所以我认为将我们的应用程序/有效时间结束日期也设置为 9999-12- 是个好主意31 23:59:59.9999999。

但是，有人问我“为什么我们不能将其设置为 NULL 以表示主表中的句点没有结束？”

那为什么呢？为什么 MS 选择使用 9999-12-31 23:59:59.9999999 而不是 NULL？

是否像使查询（可能）更容易编写一样简单？我猜 BETWEEN 对两个实际日期值的效果更好，但我想不出更多。

我正在尝试使用 myBatis 检索 SQL Sever 临时表的 SYSSTARTTIME 字段的值，但无法弄清楚。我有这样的事情：

当我运行它时，虽然我可以在控制台日志记录中看到插入，但是它会抛出一个异常，说必须声明 @MyTableVar，所以就像插入后表变量超出范围并且标签运行就像常规 SELECT

我也尝试过生成键的功能，但 myBatis 期望键是表中我自动生成的 SYSTEMSTARTTIME 不是的第一个字段。

我有一个历史表，我想将其转换为 sql server 时态历史表。每天，我都会对数据进行快照并将其添加到表中，而不管更改如何。我可以使用它来获取一年中每一天的时间点。因为我有 3 年的数据，所以我可以对每一年的一天进行 3 年的比较。无论如何，这些表变得相当大。我们想开始使用临时表。我一直在试图弄清楚我是否可以根据当前表中添加的日期将这些历史表转换为具有正确起始日期和截止日期的时间历史表。我发现的例子似乎不允许这样做。有任何想法吗？谢谢。

我尝试在 Visual Studio 2017 和 SQL Server Data Tools (SSDT) 中使用 SQL Server 临时表。

但我立即收到以下错误：

SQL71609：系统版本化的当前表和历史表没有匹配的架构。不匹配的列：'[dbo].[MyTable].[ValidFrom]'

我看不出有什么错误。我错过了什么吗？

我在 GIT HUB 上创建了一个小型存储库用于复制

当前表定义为：

和历史表：

我需要一个数据存储，它不仅要维护对数据所做的更改的历史记录（很容易做到），还要存储对数据的任意数量的提议更改，包括链式提案（即提案提案）。

将这些“更改”视为真正长时间运行的事务，这些事务被保存到数据库中，并且具有几分钟到几年的生命周期。

它们被创建（提议），然后回滚（基本上删除）或提交，当提交时，它们成为对第 3 方可见的有效数据。

当然，这一切都需要某种形式的冲突解决，因为提议的更​​改可能处于相互矛盾的状态（例如，更改 A 建议删除记录，但更改 B 建议更新它 - 如果首先提交更改 A，那么更改 B 将不得不恢复）

我发现没有现成的产品可以做到这一点。最接近的是 Oracle Workspace Manager，但它不提供 change-on-change 或查看建议删除的功能。我能够做到这一点的唯一方法是在我的版本化表上有一组公共列：

根 ID：必需 - 在创建记录的第一个版本时设置一次与主键相同的值。这代表了所有时间的主键，并被复制到记录的每个版本中。命名关系列时应考虑根 ID（例如 PARENT_ROOT_ID 而不是 PARENT_ID）。由于根 ID 也是初始版本的主键，因此可以根据实际主键创建外键 - 实际所需的行将由下面定义的版本过滤器确定。

更改 ID：必需 - 通过更改创建、更新、删除每条记录

Copied From ID : Nullable - null 表示新创建的记录，not-null 表示该行在更新/删除时是从哪个记录 ID 克隆/分支的

从日期/时间开始生效：可为空 - 空表示建议的记录，非空表示记录何时成为当前记录。不幸的是，不能在 Root ID/Effective From 上放置唯一索引，因为任何 Root ID 都可以有多个空值。（除非您想将自己限制为每条记录的单个建议更改）

生效日期/时间：可为空 - 空表示当前或建议，非空表示何时成为历史。技术上不需要，但有助于加快查找当前数据的查询。此字段可能会被手动编辑损坏，但如果发生这种情况，可以从生效日期/时间重建。

删除标志：布尔值 - 当建议在成为当前记录时删除记录时设置为 true。提交删除时，它们的生效日期/时间设置为与生效日期/时间相同的值，将它们从当前数据集中过滤掉。

在某个时间点获取当前数据状态的查询将是；

根据更改获取数据当前状态的查询将是；

请注意，此第二个查询包含第一个基于时间的查询，以将当前数据与建议的更改数据重叠。

更改 ID 列是指更改表的主键，该表还包含提供更改时更改功能的父 ID 列（可为空）。因此，第二个查询指的是更改 ID ，而不是单个更改 ID。我在客户端的 change-on-change 场景中过滤多个版本，而不使用 SQL，因此在这些查询中看不到它（客户端在内存中有一个更改 ID 的链接列表，如果检索到超过 1 个版本的行它使用链表来确定使用哪个版本）。

有人知道我可以使用的现成产品吗？我自己处理这个版本控制并引入了各种问题是大量的工作。

我想将现有表转换为临时表，它有 2 个计算列（用户定义函数）。

我已经使用下面的脚本将 3 列添加到我的表中，并且成功。

但是当我试图执行下面的脚本时

我收到以下错误

我错过了什么重要的事情吗？