Question

我有一个TSQL视图，该视图在SQL Server 2016环境中处理多个GB的数据。在此视图中，我多次比较DateTime值是在静态日期之前还是之后（通常以'2018-07-11'之类的字符串表示）。

一个比较示例是：

SELECT MyId, MyValue FROM MyTable WHERE MyDate = '2018-07-11'

在寻找一种使用DateTime文字而不是字符串的方法时，我遇到了使用ODBC DateTime字符串的示例，如下所示：

SELECT MyId, MyValue FROM MyTable WHERE MyDate = {d '2018-07-11'}

当我比较查询计划时，即使组成更高级的查询，我也会得到相同的结果。

我开始使用这种格式来尝试防止在查询中将字符串自动转换为DateTime，但是我找不到任何好的文档来说明使用ODBC函数的任何副作用。我不确定这是否与字符串文字相同或是否被解释为日期。

如果这是UDF或存储过程，则可以声明要在查询中使用的DateTime变量，但是在VIEW中这是不可能的，也不可行，因为存在很多DateTime查询实际版本中的文字。

因此，总而言之，有人对于使用此{d '2018-07-11'}格式的或有任何具体原因（除了可能不在非SQL Server环境中有效）？

我想确保我不会在这里进行代码审查。

PS：对于模糊的示例和半开放式问题，我深表歉意，不允许透露任何实际源代码。

谢谢！

编辑：我忘了提到我也可以使用DATEFROMPARTS(2018, 07, 11)，但是我不确定查询优化器是否会奇怪地查看它。

Answer 1

ODBC文字具有一点优势，即永远无法将其解释为YYYY-DD-MM，只有一种国际化设置才可以实现。

您可以使用'YYYYMMDD'格式避免歧义。此格式不受设置的影响。

我宁愿不使用ODBC，只是因为它似乎在查询中涉及更多的混乱情况。我承认也喜欢连字符形式（与ISO标准和其他数据库一致）。但是您有三种选择。对于一般用途来说，最安全的可能是纯SQL Server代码，它是非连字符形式。

Answer 2

文字是文字。在解析期间将其转换为值。该值稍后使用。

因此，如果仅使用SQL Server，则没有区别。不同的SQL风格可能会拒绝ODBC语法。我不相信这是ANSI SQL，所以“标准较低”吗？