移植性のあるSQLを書くことはどれほど必要または便利ですか？

Question

何度も、私はここや他の場所で、SQL言語の移植性のない拡張の回避を主張する人々を見てきました。これが最新の例です。私が言いたいことを述べた記事を1つだけ思い出し、そのリンクはもうありません。

移植性のあるSQLを作成し、方言の独自のツール/構文を削除することで、実際に利益を得ましたか？

誰かがmysqlで複雑なアプリケーションを構築するために苦労して、「何がただのモモだろうか」と言ったのを見たことはありません。 （PostGreSQL | Oracle | SQL Server）に切り替えましょう！

-say- PHPの一般的なライブラリは、SQLの複雑さを抽象化しますが、どのくらいのコストがかかりますか？効率的な構成体と関数を使用できなくなります。これは、おそらく使用しないと思われる移植性のかすかな光景です。これは私にとって教科書YAGNIのように聞こえます。

編集：たぶん、私が言及した例はあまりにも気味が悪いかもしれませんが、ポイントが残っていると思います。まったくしません。

Answer 1

大企業を扱うソフトウェアベンダーには選択肢がありません（実際、私の世界です）。顧客には、1つのデータベースベンダーの製品のみを使用するというポリシーがあります。主要な顧客を見逃すことは商業的に困難です。

エンタープライズ内で作業する場合、プラットフォームの知識を活用できる場合があります。

一般に、DBレイヤーは適切にカプセル化される必要があるため、新しいデータベースに移植する必要がある場合でも、変更が広範囲に及ぶことはありません。即時のマルチベンダーサポートを求める特別な要求がない限り、移植にYAGNIアプローチを採用することは合理的だと思います。現在のターゲットデータベースで動作するようにしますが、将来の移植性を可能にするためにコードを慎重に構造化します。

Answer 2

拡張機能の問題は、データベースシステム自体を更新するときに拡張機能を更新する必要があることです。開発者はコードが永遠に続くと考えることがよくありますが、ほとんどのコードは5〜10年以内に書き換える必要があります。管理者は壊れていないものを修正できないほど賢く、多くの場合、新しいバージョンごとにシステムをアップグレードしないため、データベースはほとんどのアプリケーションよりも長く生き残る傾向があります。
それでも、データベースをアップグレードするのは本当に苦痛です。まだ新しいバージョンに拡張機能がそのバージョンと互換性がないため、機能しません。アップグレードがはるかに複雑になり、より多くのコードを書き換える必要があります。
データベースシステムを選択すると、多くの場合、その決定に何年も行き詰まります。
データベースといくつかの拡張機能を選択すると、ずっとずっとずっとその決定に固執しています！

Answer 3

必要だとわかる唯一のケースは、クライアントが自分のシステムで購入して使用するソフトウェアを作成しているときです。プログラミングの大部分はこのカテゴリに分類されません。ベンダー固有のコードは通常、ANSII Standard SQLよりも特定のタスクのパフォーマンスを向上させるために記述され、そのデータベースの特定のアーキテクチャを活用するように記述されているため、ベンダー固有のコードの使用を拒否することは、パフォーマンスの悪いデータベースを確保することです。私は30年以上datbaseを使用してきましたが、企業がアプリケーションを完全に書き直さずにバックエンドデータベースを変更するのを見たことはありません。この場合、ベンダー固有のコードを回避するということは、ほとんどの場合、理由もなく理由もなくパフォーマンスを損なうことを意味します。

また、私は何年もの間、データベースバックエンドを備えた多くの異なる商用製品を使用しました。例外なく、それらのすべてが複数のバックエンドをサポートするように書かれており、例外なく、それらのすべてが日常的に実際に使用するプログラムの悲惨な、遅い犬でした。

Answer 4

大部分のアプリケーションでは、移植性の高いSQLを記述しようとすることによるメリットはほとんど、またはまったくありません。ただし、場合によっては実際の使用例があります。タイムトラッキングWebアプリケーションを構築しているとします。そして、自己ホスト型ソリューションを提供したいと思います。

この場合、クライアントにはDBサーバーが必要です。ここにはいくつかのオプションがあります。クライアントベースを制限する可能性のある特定のバージョンを使用するように強制することができます。複数のDBMSをサポートできる場合、Webアプリケーションを使用できる潜在的なクライアントが広くなります。

Answer 5

• 企業の場合、与えられたプラットフォームを使用します
• ベンダーの場合、複数のプラットフォームを計画する必要があります

企業の寿命：

• おそらく、DBMSを移行する前にクライアントコードを書き換えます
• DBMSはおそらくクライアントコードよりも長持ちします（Javaまたはc＃の'80メインフレーム）

覚えておいてください：

プラットフォーム内の

SQLは通常下位互換性がありますが、クライアントライブラリには互換性がありません。 OSが古いライブラリ、セキュリティ環境、ドライバーアーキテクチャ、または16ビットライブラリなどをサポートできない場合、移行を強制されます

つまり、SQL Server 6.5にアプリがあると仮定します。 SQL Server 2008でもいくつかの調整を加えて実行されます。まともなクライアントコードを使用していないのは間違いありません...

Answer 6

「最低公約数」を使用することには、常にいくつかのメリットとコストがあります。移植性を保護するための言語の方言。言語、オブジェクトおよび関数ライブラリ、レポートライターなどをプログラミングするための同様の危険性と比較すると、特定のDBMSへのロックインの危険性は低いと思います。

これは、将来の移植性を保護する主な方法として推奨するものです。テーブル、列、制約、およびドメインを含むスキーマの論理モデルを作成します。 SQLデータベースのコンテキスト内で、できる限りDBMSに依存しないようにします。方言に依存する唯一のものは、いくつかのドメインのデータ型とサイズです。一部の古い方言にはドメインサポートがありませんが、とにかくドメインに関して論理モデルを作成する必要があります。 2つの列が同じドメインから引き出され、共通のデータ型とサイズを共有するだけではないという事実は、論理モデリングにおいて非常に重要です。

論理モデリングと物理モデリングの違いを理解していない場合は、それを学んでください。

できるだけ多くのインデックス構造を移植可能にします。各DBMSには独自の特別なインデックス機能がありますが、インデックス、テーブル、列の関係はDBMSにほぼ依存しません。

アプリケーション内でのCRUD SQL処理の観点から、必要に応じてDBMS固有の構造を使用しますが、文書化しておくようにしてください。例として、Oracleの「CONNECT BY」を使用することをheしません。私はそれが私にいくつかの良いことをすると思うたびに構築します。論理モデリングがDBMSに依存していない場合、CRUD SQLの多くは、ユーザーの多大な努力がなくてもDBMSに依存しません。

移動するときが来たら、いくつかの障害を予期しますが、体系的な方法でそれらを克服することを期待します。

（上記の「あなた」という言葉は、特にOPではなく、懸念される人に当てはまります。）