バックエンドでDBを簡単に切り替えることができるアプリケーションが必要だったとしましょう。
私は主にSQLServerをプライマリバックエンドとして考えていますが、別のDBエンジンに柔軟に対応できます。FirebirdとPostGreSQLは、（私の簡単なウィキペディアの遠足から）SQL Serverと最も共通しているようです（さらに、それらは無料です）。
DBのセットアップ、アクセス、クエリなどは、Firebird、PostGreSQL、およびMS SQL Serverでどの程度似ていますか？
残念ながら、SQLはプロバイダーによって大きく異なります。多数のRDBMSで実行する最も些細なSQLを除いてすべてを作成することはほとんど不可能です。そうすると、最小公分母の領域に入ります。少なくともデータベースへの接続（アクセス、クエリの送信を含む）を処理するために抽象化レイヤーを使用し、SQL自体またはプロバイダーごとのSQLを処理するためにORMを使用する方がはるかに優れています。
それらがどのように変化するかを調べたい場合-良い例は、IDを自動インクリメントし、最後に挿入されたレコードのIDを取得することです。
私は、少なくとも Access、SQL Server、および Oracle を含む多くのデータベースをサポートすることが絶対条件である 1 つのプロジェクトに取り組みました。
だから私はそれができることを知っています。ほとんどの DML (SELECT、UPDATE、INSERT...) は同じであり、確かに、すべてのデータベースで動作させるのに大きな問題はありませんでした。当時、MySQL は十分な機能を備えていなかったため、例外でした。
ほとんどの違いは DDL に見られましたが、適切なアーキテクチャ (私たちが持っていたもの) があれば、これを修正するのは難しくありませんでした。
問題を引き起こした唯一のことは、一意の ID を生成することでした。自動インクリメントは標準ではありません。幸いなことに、約 40 のテーブルからなるデータベースでは、一意の ID が必要な場所はわずかしかありませんでした (適切な DB 設計)。最後に、コードで一意の ID を生成し、衝突 (トランザクション内のすべて) を処理します。
ID フィールドに自動インクリメントを使用することを避けていたので、作業は簡単になりました。一意のキーを考えるのは難しくなりましたが、長期的には改善されました。
CRUD はどこでも同じはずですが、何か複雑なものを作成する場合は、おそらくトリガーとストアド プロシージャを使用する必要があり、互換性が低くなります。通常、DBMS に依存しないアプリケーションを作成するということは、ほとんどのビジネス ロジックをデータベースの外に移動することを意味するため、3 層アプリケーションを用意することは、そのような場合には必須です。
あるいは、抽象化レイヤーのように機能するラッパー ライブラリを使用することもできますが、さまざまな DBMS で正しく機能するラッパー ライブラリをまだ見ていません。もちろん、それは使用するプログラミング言語にも依存します。
他の回答で指摘されているように、基本的な SELECT/INSERT を超えると (場合によってはそこにさえ)、DBMS は大きく異なります。
また、複数の DBMS 間で互換性を維持する必要があります。私の意見では、最善のアプローチは通常、ある種の互換性レイヤーを使用することです。社内に DB 抽象化ライブラリがありますが、いくつかのツールが利用可能です。
特に、人気のある ORM (Hibernate、nHibernate など) を調べてみるとよいでしょう。それらは通常、一種の副作用として DB 非依存性を提供します。少なくとも Hibernate には、使用している DBMS の SQL に自動的に変換される特別なクエリ言語もあります。