SQL Server 2016の移植性を最大化するためのベストプラクティス
ソリューションのプロトタイプの開発に関しては、多くの場合、テクノロジーはまだ決定されておらず、完成品で使用されるものと同じではない場合があります。
このシナリオでは、別のサーバーへの最終的な移行を簡略化するために、Microsoft SQL Serverを使用してクエリをできるだけ標準的に作成する傾向があります。
SQL Serverで直接、または SQL Server Management Studio （SSMS）を介して標準SQL over T-SQLダイアレクトの使用を強制する方法またはいくつかの既知の方法はありますか？
ユーザー Aaron Bertrand は、あなたの質問に対する私の考えとよく一致するコメントをいくつかしました。これは具体的な質問への回答というよりはフレームチャレンジですが、この文脈で検討することは価値があると思います。
移植性は素晴らしい教科書の目標ですが、実際にはめったに起こりません。
ある時点でプラットフォームを変更する必要がある場合、アプリケーション、データベース、およびおそらく他の多くのものに必要な変更があります。あまり努力せずに「プラットフォームにとらわれない」ことがある程度できれば、それは問題ありません。しかし、それを設計目標として使用することは、実に悪いビジネス決定です。
オンラインで人々が欠点やこの方法でプログラミングについて話し合う場所はたくさんあります。ここに、私が非常に説得力があると思う場所の1つを示します。
移植性の誤り
著者は私がいつも聞く引数を使用します。優れた抽象化レイヤーを使用すれば、$ this_databaseから$ other_databaseに簡単に移動できます。
それはでたらめです。それは決して簡単なことではありません。
重要なデータベースを使用するアプリケーションでは、データベースを切り替えるのは簡単なことではありません。 「改宗は痛みを伴わない」と考えることは、幻想です。
優れたエンジニアは、仕事に最適なツールを選択し、ツールのユニークで最も強力な機能を活用するためにできる限りのことを行います。データベースの世界では、これは特定のヒント、インデックス、データ型、さらにはテーブル構造の決定さえも意味します。すべての主要なRDBMSに共通する機能のサブセットに自分自身を本当に制限するのであれば、自分自身とクライアントに大きな不利益をもたらしています。
これは、「PHPのサブセットに自分を制限するためにやっているのです。これはPerlとCでも同じです。言語を1日切り替えて「無痛」で移植したい場合があるからです。コード。"
それは起こりません。
アプリケーションの開発およびデプロイ後にデータベースを切り替えるコストは非常に高くなります。可能なスキーマとインデックスの変更、構文の変更、再実行するための最適化とチューニング作業、調整または削除するためのヒントなどがあります。 mysql_foo（）をOracle_foo（）に変更することは、実際には問題の最小です。すべてではないにしても、SQLのほとんどを操作するか、少なくとも検証する必要があります。
それは私にとって「無痛」に聞こえません。
STD SQLを強制しません。
最初に、プロジェクトのニーズに応じて使用するDBMSを決定し、それを利用します。
あんまり。
_SET FIPS_FLAGGER 'FULL'_ があります。
これは非標準SQLの警告を出力します-しかし、いくつかの警告は
- これが使用する特定の標準が不明です（SQL 92である可能性があります）
- 簡単なテストから、これは_
+_演算子を文字列連結またはGETDATE()などの独自の関数に使用することに不満がないため、あまり包括的ではないようです。
「多くの場合、技術はまだ決定されていません」
私の経験では、これはまったく当てはまりません。実際、おそらく非常に小さなものを除いて、これを聞いたことがないと思います。
通常これが確立され、新しいソリューションはすでに使用されているものを利用することが期待されています。
上記のコメンターには同意しません。たとえそれが確立されていなくても、クエリやその他のコードの記述を開始する前に、まずそれを確立する必要があります。さもなければ、あなたはすぐに書き直しの多くの無駄な努力のために潜在的に自分自身を許しているだけです。