在 SQL Server 2016 中最大化可移植性的最佳實踐
在開發解決方案的原型時，通常尚未確定技術，並且可能與最終產品中使用的技術不同。
在這種情況下，我傾向於使用 Microsoft SQL Server 編寫盡可能標準的查詢，以簡化最終遷移到另一台伺服器的過程。
有沒有一種方法或一些已知的做法可以直接在 SQL Server 中或通過SQL Server Management Studio (SSMS)強制使用標準 SQL 而不是 T-SQL 方言？
使用者Aaron Bertrand的一些評論與我對您的問題的想法非常吻合。這更像是一個框架挑戰，而不是對您的具體問題的回答，但我認為在這種情況下考慮這一點很有價值。
可移植性是一個很好的教科書目標，但在實踐中很少發生。
如果您必須在某個時候更改平台，則需要對應用程序、數據庫以及許多其他內容**進行更改。**如果您無需太多努力就可以在某種程度上“與平台無關”，那很好。但將其用作設計目標確實是一個糟糕的商業決策。
網上有很多地方人們會討論這種方式的缺點或程式，這裡有一個我覺得非常引人注目的地方：
可移植性謬誤
作者使用了我一直聽到的一個論點：如果你使用一個好的抽象層，它會很容易從 $ this_database to $ other_database 在路上。
那是胡說。這從來都不容易。
在任何重要的數據庫支持應用程序中，沒有人認為切換數據庫是一件容易的事。認為“轉換將是無痛的”是一種幻想。
優秀的工程師會嘗試為工作選擇最好的工具，然後儘其所能利用他們工具的獨特和最強大的功能。在數據庫世界中，這意味著特定的提示、索引、數據類型，甚至表結構決策。如果您真的將自己限制在所有主要 RDBMS 中通用的功能子集，那麼您對自己和您的客戶都是極大的傷害。
這與說“我正在努力將自己限制在 Perl 和 C 中相同的 PHP 子集，因為我可能希望有一天切換語言並‘無痛’地移植我的程式碼”沒有什麼不同。
那隻是不會發生。
在開發和部署應用程序後切換數據庫的成本相當高。您有可能的模式和索引更改、語法更改、優化和調整工作要重新做、提示要調整或刪除，等等。將 mysql_foo() 更改為 oracle_foo() 確實是您最少的問題。您將觸及大部分（如果不是全部）您的 SQL，或者您至少需要驗證它。
這對我來說聽起來並不“無痛”。
不要強制執行 STD SQL。
首先根據項目的需要確定您將使用哪個 DBMS，並利用它。