SQL Server 2016の移植性を最大化するためのベストプラクティス

ソリューションのプロトタイプを開発する場合、多くの場合、テクノロジーはまだ決定されておらず、完成品で使用されるものと同じではない可能性があります。

このシナリオでは、別のサーバーへの最終的な移行を簡略化するために、Microsoft SQL Serverを使用してクエリをできるだけ標準的に作成する傾向があります。

SQL Serverで直接、またはSQL Server Management Studio（SSMS）を介して、T-SQLダイアレクトを介した標準SQLの使用を強制する方法またはいくつかの既知の方法はありますか？

ユーザーAaron Bertrandが、あなたの質問に対する私の考えとよく一致するコメントをいくつかしました。これは具体的な質問への回答というよりは、フレームチャレンジのようなものですが、この文脈で検討することは価値があると思います。

移植性は教科書の素晴らしい目標ですが、実際にはめったに起こりません。

あなたはいくつかの点でプラットフォームを変更する必要がある場合は、そこになり、アプリケーションに必要な変更、データベース、およびおそらく他の多くのもの。あまり努力せずに「プラットフォームにとらわれない」ことができれば、それは問題ありません。しかし、それを設計目標として使用することは、実に悪いビジネス決定です。

オンラインで人々が欠点やこのようにプログラミングについて議論する場所はたくさんあります。ここに私が非常に説得力があると思うものの1つを示します。

データベース抽象化レイヤーは死ぬ必要があります！

移植性の誤り

著者は私がいつも聞く引数を使用します。優れた抽象化レイヤーを使用すれば、$ this_databaseから$ other_databaseに簡単に移動できます。

それはでたらめです。それは決して簡単なことではありません。

重要なデータベースを使用するアプリケーションでは、データベースを切り替えるのは簡単なことではありません。「改宗は痛みを伴わない」と考えることは、幻想です。

優れたエンジニアは、仕事に最適なツールを選択し、ツールのユニークで最も強力な機能を活用するためにできる限りのことを行います。データベースの世界では、これは特定のヒント、インデックス、データ型、さらにはテーブル構造の決定さえも意味します。すべての主要なRDBMSに共通する機能のサブセットに自分自身を本当に制限するのであれば、自分自身とクライアントに大きな不利益をもたらしています。

それは、「PerlとCで同じPHPのサブセットに制限するためにやっているのです。いつか言語を切り替えて、コードを「無痛」に移植したいからです。」

それは起こりません。

アプリケーションの開発およびデプロイ後にデータベースを切り替えるコストは非常に高くなります。可能なスキーマとインデックスの変更、構文の変更、再実行するための最適化とチューニング作業、調整または削除するためのヒントなどがあります。mysql_foo（）をoracle_foo（）に変更することは、実際には問題の最小です。すべてではないにしても、SQLのほとんどを操作するか、少なくとも検証する必要があります。

それは私にとって「無痛」に聞こえません。

STD SQLを強制しません。

最初に、プロジェクトのニーズに応じてどのDBMSを使用するかを決定し、それを利用します。

あんまり。

ありますSET FIPS_FLAGGER 'FULL'。

これは非標準SQLの警告を出力しますが、いくつかの警告があります

• これが使用する特定の標準が不明です（SQL 92である可能性があります）
• 簡単なテストから、これは+文字列連結や独自の関数などの演算子の使用について不満がないGETDATE()ため、あまり包括的ではないようです。

「多くの場合、技術はまだ決定されていません」

私の経験では、これはまったく当てはまりません。実際、おそらく非常に小さなものを除いて、これを聞いたことがないと思います。

通常これが確立され、新しいソリューションはすでに使用されているものを利用することが期待されています。

上記のコメンターには同意しません。確立されていない場合でも、クエリやその他のコードの記述を開始する前に、まずそれを確立する必要があります。それ以外の場合は、すぐに書き直すことで多くの無駄な努力をする可能性があります。