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

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

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

有没有一种方法或某种已知的实践可以直接在SQL Server中或通过SQL Server Management Studio（SSMS）通过T-SQL方言强制使用标准SQL ？

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

可移植性是一个不错的教科书目标，但实际上很少发生。

如果您必须在某个时候更改平台，则将需要对应用程序，数据库以及可能的许多其他事物进行更改。如果您无需过多努力就可以“与平台无关”，那很好。但是，将其用作设计目标确实是一个错误的业务决策。

在线上有很多地方，人们在讨论这些缺点或以这种方式进行编程时，我发现其中之一很引人注目：

数据库抽象层必须消亡！

可移植性谬误

作者经常听到我使用的一个论点：如果您使用了良好的抽象层，那么很容易从$ this_database迁移到$ other_database。

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

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

优秀的工程师会尝试为工作选择最佳的工具，然后尽其所能以利用其工具的独特和最强大的功能。在数据库世界中，这意味着特定的提示，索引，数据类型，甚至表结构决策。如果您真正地将自己限制在所有主要RDBMS通用的功能子集中，那么您和您的客户就会受到极大的损害。

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

那只是没有发生。

开发和部署应用程序后切换数据库的成本非常高。您可能需要更改架构和索引，更改语法，重新进行优化和调整，提示要调整或删除等等。将mysql_foo（）更改为oracle_foo（）确实是最少的问题。您将接触到大部分（如果不是全部）SQL，或者至少需要进行验证。

对我而言，这听起来并非“无痛”。

不要强制执行STD SQL。

首先根据项目需求确定要使用的DBMS，并加以利用。

并不是的。

有SET FIPS_FLAGGER 'FULL'。

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

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

“通常技术尚未决定”

我会说这绝对不是我的经验。实际上，除了一些很小的东西外，我不相信我听说过。

通常这是建立的，并且新的解决方案有望利用已经使用的解决方案。

我同意上面的评论者的观点，即使它没有被建立，您也需要在开始编写查询和其他代码之前先建立它。否则，您可能会浪费大量精力立即进行重写。