Delphi Win32 アプリケーションから MS SQL、Oracle、または Firebird に接続するには、ADO と DBX (Database Express) のどちらを使用するのが適していますか (また、その理由は何ですか?)。
どちらも主要なデータベースに接続できます。ADO が接続文字列の変更ですべてを行う方法と、ADO とドライバーが Windows に含まれているため、展開する余分なものがないという事実が気に入っています (間違っている場合は修正してください)。
DBX も柔軟性があり、ドライバーをアプリにコンパイルできますか?
可能であれば、顧客の IT 部門や好みに応じてデータベースを変更できる単一のソースを用意したいと考えています。
しかし、プログラミングが簡単で、パフォーマンスが高く、メモリを最も効率的に使用できるのはどれでしょうか? それらを区別する他のものはありますか？
ありがとう、リチャード
ADO は簡単に使用できます。対応するクライアント ドライバーをクライアント側にインストールするだけで済みます。
DBX の方が柔軟性が高く、IDE や DataSnap などの他のテクノロジとの統合が優れていることがわかりました。
あなたと同じ目的で、DevArtのサードパーティ ドライバーで DBX を使用しました。ドライバーのソースを購入すると、アプリケーションでドライバーをコンパイルできます。
Delphiの初めに、人々はDelphiでのマルチDBMSサポートを賞賛しました。誰もがBDEを愛していました（それがそれを行う唯一の方法だったからです）。
しかし、過去10年以上にわたって顧客を見ると、アプリケーションでのマルチDBMSサポートが着実に減少していることがわかりました。
1つのアプリケーションから複数のDBMSをサポートするコストは高くなります。
各DBMSの知識が必要なだけでなく、各DBMSには独自の特殊性のセットがあり、データアクセス層に適応する必要があるためです。これらには、構文と基礎となるデータ型の違いだけでなく、最適化戦略も含まれます。
また、一部のDBMSはADOでより適切に機能し、一部は直接接続でより適切に機能します（Oracleクライアントをすべてスキップするなど）。
最後に、ソフトウェアと複数のDBMSシステムのすべての組み合わせをテストすることは非常に集中的です。
私は、DBMSバックエンドやデータアクセステクノロジを変更する必要があるいくつかのプロジェクトに携わってきました（つまり、BDEからDBXに、またはDBXから直接接続に）。バックエンドの変更は、データアクセステクノロジーの変更よりも常にはるかに苦痛でした。多層アプローチはそれらをいくらか簡単にしましたが、自由度を高め、そのためテストの努力を増やしました。
マルチDBMSをサポートしていると私が思う製品のいくつかは、最終顧客がすでに独自のDBMSインフラストラクチャを持っており、アプリケーションがそれに適応する必要がある垂直市場アプリケーションにあります。たとえば、オランダの政府機関では、Oracleは非常に強力ですが、SQLServerもかなりのユーザーベースを確立しています。
したがって、機能だけでなくコストの観点からも、サポートするDBMSの組み合わせを検討する必要があります。
1つのDBMSに固執する場合、BDE、DBX、またはADOのような汎用データアクセス層を選択することは意味がありません。可能な限り直接接続を行うことで利益が得られます。私の経験から、これらの組み合わせはうまく機能することがわかりました。
ADOを使用するMicrosoftSQLServer
これにより、Delphiアプリケーションから複数のDBMSをサポートする可能性と制限についての洞察が得られることを願っています。
--jeroen
私の 2 セント: DBX は (oracle と sql の両方で) 大幅に高速であり、デプロイが非常に面倒で困難です。
パフォーマンスが重要な要素である場合、DBX を使用します。それ以外の場合は、簡単にするために ADO を使用します。
一般的な規則: コンポーネントのすべてのレイヤーは、バグのレイヤーを追加する可能性があります。ADO と DBX はどちらも、標準データベース機能のコンポーネント ラッパーであるため、どちらも同等に強力です。したがって、適切な選択は、使用するデータベースなど、他の要因に基づいている必要があります。MS-Access または SQL Server に接続する場合は、これらのデータベースに対してよりネイティブであるため、ADO を選択することをお勧めします。ただし、Firebird と Oracle は、DBX コンポーネントに対してよりネイティブです。
ただし、私は個人的に生の ADO API を使用する傾向があります。繰り返しになりますが、私は自分のプロジェクトでデータベース対応コンポーネントを使用していません。それはそれほどRADではありません、私は知っています。しかし、私は通常、データベースと GUI の間に複数のレイヤーを持つクライアント/サーバー アプリケーションを作成するため、この方法で作業する必要があり、物事がより複雑になります。
他の人が言っているように、DBXは特定の場合または特定の状況下で生のパフォーマンスで優位に立つ可能性がありますが、ADOは世界中の非常に多くのアプリケーションの基盤であるため、ADOのパフォーマンスは比較的劣る可能性がありますが、明らかにそうではありません。 「容認できないほど」貧しいという意味です。
私自身、そして私が取り組んできた主要なプロジェクトから情報を得たところ、DBXの最大の「問題」は、それがどんなに優れていても、言語/ツール会社が提供する重要なインフラストラクチャテクノロジであるということです。
以前のBDEテクノロジでアプリケーションを構築した人は誰でも、そのテクノロジが非推奨になり、サポートされなくなったときに発生した混乱を証言します。プロバイダーによる非推奨の影響を受けないテクノロジーはありませんが、テクノロジープロバイダー自体を超えた業界サポートに関しては、ADOが明らかに優位に立っています。
そのため、私自身も常にADOを使用しています。ただし、あるデータベースタイプから別のデータベースタイプに変更するときに心配するのは、接続文字列を変更することだけではありません。ストアドプロシージャの呼び出し構文はADOプロバイダーごとに異なる可能性があり、SQLサポートが異なる可能性がある複数の異なるSQLエンジンに対して展開する場合は、使用するSQL構文を監視する必要があります。
これらの問題を軽減するために、私はADOオブジェクトモデルの独自のカプセル化を使用します。このカプセル化は、オブジェクトモデルをADOに似ていないものに変更しようとはしません。これは、ObjectPascalに適した（「タイプ」セーフな）形式（列挙型や数百の整数定数ではないにしてもスコアだけでなく、定数やフラグなどのセット）。
私のカプセル化は、前述のストアドプロシージャ呼び出し構文の違いなど、さまざまなプロバイダーの動作/要件のマイナーなバリエーションのいくつかも処理します。
また、別のポスターと同様に、私はずっと前に「データ認識コントロール」の使用をやめました。これにより、このアプローチが可能になります。データ対応コントロールが必要または使用したい場合で、ADOを使用したい場合は、ADOを直接使用することはできず、代わりにVCLデータセットモデルを介してADOを公開するカプセル化を見つける必要があります。
ADOはMicrosoftの世界です
DBXは、クロスプラットフォームとKylix用に最初に作成されました（Delphi 6）。