8

上司から、ANSI SQL だけを記述してデータベースに依存しないようにするように言われました。しかし、ANSI SQL と完全に互換性のあるデータベースはないため、それほど簡単ではないことを知りました。SQL コードを変更せずにデータベース システム間で移植できることはめったにありません。

プログラムデータベースを独立させるために、人々がさまざまな方法を行っているのを見ました。例えば：

  1. SQL ステートメントをリソース ファイルに外部化します。
  2. さまざまなデータベースをサポートするために、多くのプロバイダー クラスを記述します。
  3. 単純な SQL のみを記述し、高度な関数や結合は避けてください。

あなたは常に「任意のデータベース対応」のコードを書いていますか? それとも必要な場合のみ行いますか？はいの場合、どのようにそれを達成しますか?

4

5 に答える 5

7

Hibernate/NHibernate、LLBLGen などの多くのオブジェクト/リレーショナル マッパー ツールのいずれかを使用できます。これにより、データベースの移植性が大幅に向上します。何をするにしても、モデルと残りのコードの間に何らかの抽象化レイヤーが必要です。これは、ある種の依存性注入インフラストラクチャが必要だという意味ではありませんが、優れた OO 設計によってかなりのことが実現できます。また、単純な SQL に固執し、それによって移植性が得られると考えるのは、かなり単純です。アプリケーションが単純で、非常に単純なクエリしか使用しない場合は、これが当てはまります。

常に「任意のデータベースに対応」するアプリケーションを作成する場合、私は通常、ある種の抽象化レイヤーを使用するので、あるデータベース システムから別のデータベース システムに移動するのは難しくありません。ただし、多くの場合、これは必須ではありません。Oracle プラットフォーム、SQL Server、または MySQL 向けに開発しているため、完全にシームレスな移行の可能性のためだけに、選択した RDBMS の利点を犠牲にするべきではありません。それにもかかわらず、適切な抽象化レイヤーを構築すれば、特定の RDBMS をターゲットにすることでさえ、別の RDBMS に移行するのが必ずしも難しいとは限りません。

于 2008-12-21T16:33:47.240 に答える
6

アプリケーションからデータベース エンジンを切り離すには、データベース抽象化レイヤー (データ アクセス レイヤー、または DAL) を使用します。使用する言語については言及されていませんが、主要なすべての言語用の優れたデータベース抽象化ライブラリがあります。

ただし、データベース固有の最適化を回避すると、特定のブランドの利点を逃すことになります。私は通常、可能なことを抽象化し、利用可能なものを使用します。データベース エンジンの変更は重大な決定であり、頻繁に行われるわけではありません。使用可能なツールを最大限に使用することをお勧めします。

于 2008-12-21T16:35:41.997 に答える
3

上司に自分のことを気にするように言いなさい。いいえ、もちろん上司にそんなことは言えませんが、ご期待ください。

興味深いのは、この要件によってどのようなビジネス価値がサポートされると想定されているかということです。明らかな候補の 1 つは、データベース コードが現在のデータベース エンジン以外のデータベース エンジンで動作する準備が整っていることです。その場合は、要件に記載する必要があります。

そこから、それを達成するためのさまざまな方法を見つけ出すのは、エンジニアとしてのあなた次第です。ANSI SQL を書いているかもしれません。データベース抽象化レイヤーを使用している可能性があります。

さらに、さまざまな代替案のコスト (パフォーマンス、開発速度など) を上司に知らせるのはあなたの責任です。

「ANSI SQL を書きなさい」... ガッ！

于 2008-12-21T17:08:54.987 に答える
1

記録のために。Stackoverflow にも同様の質問があります。

データベースに依存しないアプリケーションのデータベース設計

于 2008-12-21T17:19:37.117 に答える
1

ANSI SQL に 100% 準拠することは困難な目標ですが、とにかく移植性を保証するものではありません。だから、それは人工的な目標です。

おそらく、あなたの上司は、将来の仮想的な目的のためにデータベースのブランドを簡単かつ迅速に切り替えることができるようにするために、これを求めているのでしょう (実際には決して起こらないかもしれません)。しかし、コードをデータベース中立にするのが難しくなるため、彼はその将来の効率性と引き換えに今より多くの作業を行っています。*

したがって、現在のプロジェクト フェーズを予定どおりに予算内で完了するなど、マネージャーが注力すべき目標の観点から問題を表現できる場合は、コードをデータベース中立にするのは難しすぎると伝えるよりも効果的かもしれません。 .

真にデータベースに中立なコードを作成する必要があるシナリオがあります。つまり、複数のブランドのデータベースをサポートする必要があるシュリンク ラップ アプリケーションを開発している場合です。

とにかく、現在 1 つのブランドしかサポートしていない場合でも、独自の機能を使用して一部の SQL をコーディングする選択肢がある場合は確かにありますが、同じ結果を達成するためのより移植性の高い方法も存在します。これらを「簡単に達成できる」ケースとして扱うことができ、必要に応じて将来的にコードを移植しやすくすることができます。しかし、自分自身を制限しないでください。価値がある場合は、独自のソリューションを使用してください。ポートを作成する必要がある場合は、これはレビューに値するというメモをコメントに追加してください。

*プラットフォームに依存しないことについて話すときは、「不可知論者」ではなく「中立」という言葉を好みます。それは宗教的な倍音を避けます。:-)

于 2008-12-21T22:13:57.537 に答える