在 SQL Server 2016 中最大化可移植性的最佳实践

Question

在开发解决方案的原型时，通常还没有确定技术，并且可能与最终产品中使用的技术不同。

在这种情况下，我倾向于使用 Microsoft SQL Server 编写尽可能标准的查询，以简化最终迁移到另一台服务器的过程。

是否有一种方法或一些已知的做法可以直接在 SQL Server 中或通过SQL Server Management Studio (SSMS)强制使用标准 SQL over T-SQL 方言？

Answer 1

用户Aaron Bertrand发表了一些评论，这些评论与我对您的问题的想法非常吻合。这更像是一个框架挑战，而不是对您的特定问题的回答，但我认为在这种情况下考虑是有价值的。

可移植性是一个很好的教科书目标，但在实践中很少发生。

如果您在某个时候必须更改平台，则应用程序、数据库以及许多其他方面可能需要进行更改。如果您可以毫不费力地有点“平台不可知论”，那很好。但将其用作设计目标确实是一个糟糕的商业决策。

网上有很多地方人们会以这种方式讨论缺点或编程，以下是我觉得非常引人注目的一个地方：

数据库抽象层必须死！

可移植性谬误

作者使用了我一直听到的一个论点：如果你使用一个好的抽象层，那么从 $this_database 到 $other_database 会很容易。

那是胡说。这从来都不容易。

在任何非平凡的数据库支持的应用程序中，没有人认为切换数据库是一件容易的事。认为“转换将是无痛的”是一种幻想。

优秀的工程师会尝试为工作选择最好的工具，然后尽其所能利用他们工具的独特和最强大的功能。在数据库世界中，这意味着特定的提示、索引、数据类型，甚至是表结构决策。如果您真的将自己限制在所有主要 RDBMS 中共有的功能子集上，那么您对您自己和您的客户都是一个巨大的伤害。

这与说“我正在努力将自己限制在 Perl 和 C 中相同的 PHP 子集上没有什么不同，因为我可能希望有一天切换语言并‘无痛地’移植我的代码。”

那不会发生。

应用开发和部署后切换数据库的成本是相当高的。您可能有架构和索引更改、语法更改、优化和调整工作要重新执行、要调整或删除的提示等。将 mysql_foo() 更改为 oracle_foo() 确实是您遇到的最少问题。您将涉及大部分（如果不是全部）您的 SQL —— 或者您至少需要对其进行验证。

这对我来说听起来并不“无痛”。

Answer 2

不要强制执行 STD SQL。

首先根据您的项目需要决定您将使用哪个 DBMS，并利用它。

Answer 3

并不真地。

有SET FIPS_FLAGGER 'FULL'。

这会打印出非标准 SQL 的警告 - 但有些警告是

• 我不确定这使用什么特定标准（并怀疑它可能是 SQL 92）
• 从快速测试来看，这并没有抱怨将+运算符用于字符串连接或专有函数，GETDATE()因此它似乎不是很全面。