0

我正在为我们的一些表实现双时态解决方案，使用本机时态表功能，以及一些自定义列和代码来处理应用程序/有效时间。

但是，我偶然发现了对 SQL:2011 标准中的内容的引用：

来自维基百科：

截至 2011 年 12 月，ISO/IEC 9075，数据库语言 SQL:2011 第 2 部分：SQL/Foundation 在表定义中包含子句以定义 “应用程序时间段表”（有效时间表）、“系统版本表”（事务时间表）和 “系统版本化的应用程序时间段表”（双时态表）

这个pdf实际上有执行此操作的代码（应用程序时）：

CREATE TABLE Emp(
ENo INTEGER,
EStart DATE,
EEnd DATE,
EDept INTEGER,
PERIOD FOR EPeriod (EStart, EEnd)
)

此代码不会在 SSMS 中运行。现在有什么改变导致这个无效的 SQL 吗？看起来以前对应用程序时间/双时态表的无证支持现在已被删除？

4

2 回答 2

1

仅仅因为它在标准中并不意味着它在任何特定的实现中。每个供应商都有一个完全标准覆盖的延伸目标，但目前还没有一个，我怀疑它会在我的有生之年发生。

目前 SQL Server 支持系统时间，但不支持应用程序时间。可能有其他供应商这样做；我不确定，因为我不关注所有成熟的 RDBMS 平台。我知道它在 SQL Server 的雷达上，但迄今为止还没有正式的公告。

PDF 中的示例就是这样：一个支持应用程序时间的平台可以做什么的示例。下一个例子是这个......

INSERT INTO Emp
VALUES (22217,
DATE ‘2010-01-01’,
DATE '2011-11-12', 3)

...这在 SQL Server 中也无效，原因不止一个，并且违反了一些最佳启动实践。正如您所建议的，也许这些东西在 DB2 中都是有效的，但标准不应该是特定于供应商的。我的意思是，根据定义，如果没有别的。

于 2018-12-12T21:41:44.347 回答
0

IBM DB2 支持您所询问的内容。将 SQL 标准视为供应商在支持某个功能时应该公开该功能的推荐方式的定义，至少在 SQL 92 之后，这是一种核心。在 SQL 方言的历史上，有时供应商领先于标准，方言出现分歧。供应商在标准化后以非标准方式实现功能可能有点愚蠢，但有时他们会这样做。左边热，右边冷；这是一个标准。它反过来工作，但人们往往会被烧伤。

在这种情况下，IBM 似乎决定一举实施该功能并使其成为标准的一部分。微软还没有决定是否值得他们这样做。

于 2019-05-03T18:44:18.050 回答