SQLレベルでのDBエンジンの互換性はどのくらいですか？

Question

バックエンドでDBを簡単に切り替えることができるアプリケーションが欲しかったとしましょう。
私は主にSQL Serverを主要なバックエンドと考えていますが、別のDBエンジンに移行する柔軟性を備えています。 FirebirdとPostGreSQLは（私の簡単なウィキペディアのエクスカーションから）SQL Serverとの共通点が最も多いようです（さらに無料です）。

DBのセットアップ、アクセス、クエリなどは、Firebird、PostGreSQL、およびMS SQL Serverでどの程度似ていますか？

Answer 1

私は、少なくともAccess、SQL Server、Oracleを含む多くのデータベースをサポートすることが絶対に必要なプロジェクトに取り組みました。

だからできることはわかっている。ほとんどのDML（SELECT、UPDATE、INSERT ...）は同じであり、確かにすべてのデータベースで機能させるのに大きな問題はありませんでした-たまに迷惑なだけです。当時はMySQLは例外でした。単に十分な能力がなかったからです。

DDLのほとんどの違いを発見しましたが、適切なアーキテクチャ（これがあった）を使用して、これを修正することは難しくありませんでした。

問題を引き起こしたのは、一意のIDの生成だけでした-自動インクリメントは非標準です。幸いなことに、約40のテーブルのデータベースには、一意のIDが必要な場所がわずかしかありませんでした（適切なDB設計）。最後に、コードで一意のIDを生成し、衝突（トランザクションのすべて）を処理します。

IDフィールドに自動インクリメントを使用することを避けたため、物事が簡単になりました。一意のキーを考えるのは難しくなりましたが、長期的には改善されました。

Answer 2

残念ながら、SQLはプロバイダーによって大きく異なります。多くのRDBMSで実行するための最も単純なSQL以外のすべてを記述することはほとんど不可能です-そして、あなたは最も一般的な分母領域にいます。少なくともデータベースへの接続（アクセス、クエリの送信など）を処理するには抽象化レイヤーを使用し、SQL自体またはプロバイダーごとのSQLを処理するにはORMを使用する方がはるかに優れています。

それらの変化を調べたい場合-良い例は、IDの自動インクリメントや、最後に挿入されたレコードのIDの取得です。

Answer 3

まあ、CRUDのものはどこでも同じでなければなりませんが、複雑なものを構築する場合は、おそらくトリガーとストアドプロシージャを使用する必要があり、互換性が低くなります。 DBMSに依存しないアプリケーションを記述することは、通常、ほとんどのビジネスロジックをデータベースの外に移動することを意味するため、このような場合、3層アプリケーションが必要です。

別の方法として、抽象化レイヤーのように機能するラッパーライブラリを使用することもできますが、DBMS-esの範囲でジョブを正しく実行できるものはまだありません。もちろん、それは使用するプログラミング言語にも依存します。

Answer 4

他の回答で指摘されているように、DBMSは基本的なSELECT / INSERTを超えると（場合によっては）大きく変化します。

複数のDBMSで互換性を維持する必要もあります。私の意見では、最善のアプローチは通常、何らかの互換性レイヤーを使用することです。社内にDB抽象化ライブラリがありますが、いくつかのツールが利用可能です。

特に、ポピュラーなORM（Hibernate、nHibernateなど）を調べると費用がかかる場合があります。それらは通常、一種の副作用としてDB独立を提供します。少なくともHibernateには、使用しているDBMSのSQLに自動的に変換される特別なクエリ言語もあります。