我有一个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环境中可能无效(？
我想确保我不会在代码审查中自食其果。
附言：我为模糊的例子和半开放式的问题道歉，我不允许透露任何实际的源代码。
谢谢！
编辑：我忘了提到我也可以使用DATEFROMPARTS(2018, 07, 11)，但我不确定查询优化器是否会奇怪地看待它。
ODBC文字的一个小优点是它永远不能被解释为YYYY-DD-MM，这可以通过一个国际化设置来实现。
使用'YYYYMMDD'格式可以避免歧义。此格式不受设置的影响。
我更喜欢不使用ODBC，只是因为它在查询中似乎涉及更多的混乱。我承认我也更喜欢连字符的形式(与ISO标准和其他数据库一致(。但你有三种选择。对于一般用途来说，可能是最安全的，SQL Server唯一的代码是非字符形式。
文字就是文字。它在解析过程中被转换为一个值。该值稍后使用。
以下是SQL Server支持的DateTime文字列表。ODBC是一种受支持的格式。
因此，如果只使用SQL Server，则没有区别。不同的SQL风格可能会拒绝ODBC语法。我不相信它是ANSI SQL，所以"不太标准"？