多くの ORM ツールとカスタム データ アクセス レイヤー (DAO パターンなど) の目標は、最小限の作業でデータベース システム全体を交換できると思われるポイントまでデータベースを抽象化することです。
一般的な DAL パターンに従うことは通常、コードでは良い考えですが、データベースを交換することは決して最小限の作業ではないようです。(コスト、トレーニング、データ移行など)
大規模なシステムで 1 つのデータベースを別のデータベースに交換し、その影響をコードで処理した経験がある人はいますか? コードから実際のデータベースを抽象化することについて心配する価値はありますか?
私は、データベースを交換できるようにすることが目的であることに同意しません。その目標に向かっているORMについて疑念を示すのは正しいと思います。
ただし、データアクセスの詳細を抽象化するため、ORMを使用します。これはオブジェクト指向プログラミングの目標ではありませんか？あなたの懸念を分離しておいてください。
（ORMツールを介した）データベース抽象化の主なユースケースは、複数のデータベースブランドで動作する製品を出荷できるようにすることだと思います。企業がデータベースベンダーを切り替えることはめったにないと思いますが、それでもそれはユースケースの1つです。
私は金銭的な理由でMySQLを使い始めた仕事をしてきました（スタートアップを考えてください）。そして、お金を稼ぎ始めたので、Oracleに切り替えたいと思いました。最終的には切り替えはしませんでしたが、オプションがあるのは良かったです。
それでも、ORMツールは完全にリークのない抽象化ではなく、移行には依然として苦痛とコストがかかることを私は知っています。構築しているものに完全に依存しますが、パフォーマンス上の理由から、通常はORMソリューションを回避するか、ある時点でベンダー固有の機能を利用することになります。
質問1：大規模なシステムで1つのデータベースを別のデータベースに交換し、コードの影響に対処した経験はありますか？
はい、試してみました。お客様は、大規模なMSAccessベースのDelphiクライアントサーバーアプリケーションを使用しています。約5年後、SQLServerへの切り替えを検討しました。問題を分析し、データベースの交換には非常にコストがかかり、いくつかの利点しか提供しないと結論付けました。お客様はデータベースを交換しないことにしました。アプリケーションはまだ正常に実行されており、顧客はまだ満足しています。
ご了承ください：
あなたが考慮しなければならない最も重要な問題：
質問2：コードから実際のデータベースを抽象化することを心配する価値はありますか？
はい。理想的な世界では、データベースを交換することは、データ接続文字列を調整することです。現実の世界では、すべてのデータベースが異なるため、これは不可能です。それらはすべてテーブルとSQLサポートを備えていますが、違いは詳細にあります。データベースの違いを抽象化によって保護できる場合は、そうしてください。サポートする必要のあるデータベースのリストを作成します。選択したデータベースシステムで違いを確認してください。違いを処理するための一元化されたコードを提供します。1つのRDBMSをサポートし、他のRDBMSを将来サポートするためのスタブを提供します。
私がデータベースの切り替えを見たのは、開発の初期段階でのHSQLから、プロジェクトの進行に伴うOracleへの切り替えだけでした。ORMはこれを簡単にしました。
私はよくDAOパターンを使用して、データサービスをスワップアウトします（データベースからWebサービスに、またはWebサービスをテストスタブにスワップします）。
ORMの場合、データベースを切り替えることができるようにすることが目標ではないと思います。さまざまなデータベース実装の複雑さから身を隠し、データのリレーショナル表現からオブジェクト表現への変換の詳細について心配する必要をなくすことです。
誰かにキャッシュを処理するORMを賢く書いてもらうことで、変更されたフィールドのみを更新したり、更新をグループ化したりする必要はありません。何か特別なものが必要な場合でも、必要に応じてSQLに戻すことができます。