申请时间段表
Application-time period tables
我正在为我们的一些 table 实施双时态解决方案，使用本机时态 table 功能，以及一些自定义列和代码来处理 application/valid 时间。
但是，我只是偶然发现了对 SQL:2011 标准中据称的内容的引用：
来自wikipedia：
As of December 2011, ISO/IEC 9075, Database Language SQL:2011 Part 2:
SQL/Foundation included clauses in table definitions to define
"application-time period tables" (valid time tables),
"system-versioned tables" (transaction time tables) and
"system-versioned application-time period tables" (bitemporal tables)
这个 pdf 实际上有执行此操作的代码（应用程序时间）：
CREATE TABLE Emp(
ENo INTEGER,
EStart DATE,
EEnd DATE,
EDept INTEGER,
PERIOD FOR EPeriod (EStart, EEnd)
)
此代码不会 运行 在 SSMS 中。现在有什么改变使这个无效 SQL 吗？看起来以前对 application-time/bitemporal tables 的未记录支持现在已被删除？
仅仅因为它在标准中并不意味着它在任何特定的实现中。每个供应商都有一个全面覆盖标准的延伸目标，但目前还没有一个，我怀疑这会在我有生之年实现。
目前SQL服务器支持系统时间，但不支持应用时间。可能有另一个供应商这样做；我不确定，因为我没有关注所有成熟的各种 RDBMS 平台。我知道它在 SQL 服务器雷达上，但迄今为止还没有正式公告。
PDF 中的示例只是：支持应用程序时间的平台可以 完成的示例。下一个例子是这样的...
INSERT INTO Emp
VALUES (22217,
DATE ‘2010-01-01’,
DATE '2011-11-12', 3)
...出于多种原因，这在 SQL 服务器中也是无效的，并且违反了一些启动最佳实践。正如您所建议的，也许这些东西在 DB2 中都是有效的，但该标准不应该是特定于供应商的。我的意思是，根据定义，如果没有别的。
IBM DB2 支持您所询问的内容。将 SQL 标准视为供应商在支持某项功能时应公开的推荐方式的定义，至少在 SQL 92 之后，这是一种核心。在 SQL 方言的历史中，有时供应商会领先于标准，方言也会出现分歧。供应商在标准化后以非标准方式实现功能可能有点愚蠢，但有时他们会这样做。左边热，右边冷；那是一个标准。它以相反的方式起作用，但人们往往会被灼伤。
在这种情况下，IBM 似乎决定实施该功能并将其实施方式一举成为标准的一部分。微软尚未决定是否值得他们为此烦恼。
我正在为我们的一些 table 实施双时态解决方案，使用本机时态 table 功能，以及一些自定义列和代码来处理 application/valid 时间。
但是，我只是偶然发现了对 SQL:2011 标准中据称的内容的引用：
来自wikipedia：
As of December 2011, ISO/IEC 9075, Database Language SQL:2011 Part 2: SQL/Foundation included clauses in table definitions to define "application-time period tables" (valid time tables), "system-versioned tables" (transaction time tables) and "system-versioned application-time period tables" (bitemporal tables)
这个 pdf 实际上有执行此操作的代码（应用程序时间）：
CREATE TABLE Emp(
ENo INTEGER,
EStart DATE,
EEnd DATE,
EDept INTEGER,
PERIOD FOR EPeriod (EStart, EEnd)
)
此代码不会 运行 在 SSMS 中。现在有什么改变使这个无效 SQL 吗？看起来以前对 application-time/bitemporal tables 的未记录支持现在已被删除？
仅仅因为它在标准中并不意味着它在任何特定的实现中。每个供应商都有一个全面覆盖标准的延伸目标，但目前还没有一个，我怀疑这会在我有生之年实现。
目前SQL服务器支持系统时间，但不支持应用时间。可能有另一个供应商这样做；我不确定，因为我没有关注所有成熟的各种 RDBMS 平台。我知道它在 SQL 服务器雷达上，但迄今为止还没有正式公告。
PDF 中的示例只是：支持应用程序时间的平台可以 完成的示例。下一个例子是这样的...
INSERT INTO Emp
VALUES (22217,
DATE ‘2010-01-01’,
DATE '2011-11-12', 3)
...出于多种原因，这在 SQL 服务器中也是无效的，并且违反了一些启动最佳实践。正如您所建议的，也许这些东西在 DB2 中都是有效的，但该标准不应该是特定于供应商的。我的意思是，根据定义，如果没有别的。
IBM DB2 支持您所询问的内容。将 SQL 标准视为供应商在支持某项功能时应公开的推荐方式的定义，至少在 SQL 92 之后，这是一种核心。在 SQL 方言的历史中，有时供应商会领先于标准，方言也会出现分歧。供应商在标准化后以非标准方式实现功能可能有点愚蠢，但有时他们会这样做。左边热，右边冷；那是一个标准。它以相反的方式起作用，但人们往往会被灼伤。
在这种情况下，IBM 似乎决定实施该功能并将其实施方式一举成为标准的一部分。微软尚未决定是否值得他们为此烦恼。