Delphi を使用した ADO または DBX
https://stackoverflow.com/questions/1305531
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
Delphi Win32 アプリケーションから MS SQL、Oracle、または Firebird に接続するには、ADO と DBX (Database Express) のどちらを使用するのが適しています (またその理由は何ですか)。
どちらも主要なデータベースに接続できます。ADO が接続文字列の変更だけですべてを行う方法と、ADO とドライバーが Windows に含まれているため、追加で展開する必要がないという事実が気に入っています (間違っている場合は訂正してください)。
DBX も柔軟なので、ドライバーをアプリにコンパイルできますね。
可能であれば、顧客の IT 部門や好みに応じてデータベースを変更できる単一のソースを用意したいと強く思っています。
しかし、プログラムが簡単で、パフォーマンスが良く、メモリを最も効率的に使用できるのはどれでしょうか?他に差別化できる点はありますか？
ありがとう、リチャード
解決
ADOを使用するのは簡単ですし、そこにある、あなただけのクライアント側でcorrepondingクライアントドライバをインストールすることを確認する必要があります。
私はより柔軟で、それはより良いIDEとDataSnapのような別の技術に統合されDBXを見つけます。
あなたよりも、同じ目的のために、私は DevArtするからサードパーティのドライバとDBXを使用していました。 あなたは、ドライバのソースを購入する場合は、アプリケーションとドライバをコンパイルすることができます。
他のヒント
Delphi の初期には、Delphi のマルチ DBMS サポートが賞賛されました。誰もが BDE を愛していました (それがそれを行う唯一の方法だったからです)。
しかし、過去 10 年以上にわたって顧客を見てみると、アプリケーションにおけるマルチ DBMS サポートが着実に減少していることがわかりました。
1 つのアプリケーションから複数の DBMS をサポートするとコストが高くなります。
各 DBMS の知識が必要なだけでなく、各 DBMS には独自の一連の特殊性があり、データ アクセス層でそれに適応する必要があるためです。これらには、構文や基礎となるデータ型の違いだけでなく、最適化戦略も含まれます。
また、一部の DBMS は ADO でより適切に動作し、いくつかは直接接続 (Oracle クライアントをまとめてスキップするなど) でより適切に動作します。
最後に、ソフトウェアと複数の DBMS システムのすべての組み合わせをテストすることは、非常に集中的な作業です。
私は、DBMS バックエンドやデータ アクセス テクノロジを変更する必要があるいくつかのプロジェクトに参加してきました。BDE から DBX、または DBX から直接接続)。バックエンドを変更することは、データ アクセス テクノロジを変更することよりもはるかに困難な作業でした。多層アプローチによりテストはいくらか簡単になりましたが、自由度が増し、テストの労力も増加しました。
マルチ DBMS をサポートしている製品の中には、最終顧客がすでに独自の DBMS インフラストラクチャを持っており、アプリケーションがそれに適応する必要がある垂直市場アプリケーションに使用されているものもあります。たとえば、オランダの政府分野では、Oracle が非常に強力ですが、SQL Server も同様にかなりのユーザー ベースを確立しています。
したがって、機能だけでなくコストの観点からも、サポートする DBMS の組み合わせを検討する必要があります。
1 つの DBMS に固執する場合、BDE、DBX、ADO などの汎用データ アクセス レイヤーを選択するのは意味がありません。できるだけ直接接続する方が効果的です。私の経験から、これらの組み合わせはうまく機能することがわかりました。
- Interbase または Firebird を使用 FIBプラス, AnyDAC, IBO または IBX*
- オラクルと AnyDAC, DOA または ODAC
Microsoft SQL Serverと ADO
- IBX は Firebird があまり好きではありません。
これにより、Delphi アプリケーションから複数の DBMS をサポートする可能性と制限についての洞察が得られることを願っています。
--ジェローン
一般的なルール：コンポーネントのすべての層はおそらくバグの追加の層を追加します。 ADOとDBXの両方は、このように、彼らは両方とも同じように強いている、標準的なデータベース機能の周りのコンポーネントラッパーです。 だから、適切な選択は、使用するデータベースのような他の要因に基づいている必要があります。あなたはMS-AccessまたはSQL Serverに接続したい場合は、これらのデータベースのためのより多くのネイティブなので、ADOは、より良い選択です。しかし、火の鳥とOracleは、DBXコンポーネントのためのより多くのネイティブです。
私は個人的にかかわらず、生のADOのAPIのを使用する傾向があります。その後、再び、私は私のプロジェクトでは、データ対応のコンポーネントを使用しないでください。それは私が知っている、あまりRADです。私は、一般的にこのように物事がより複雑になって、データベースとGUIの間にいくつかの層を持つクライアント/サーバーアプリケーションを書くので、しかし、私はしばしばこのように動作する必要があります。
私の2セント：DBXは（OracleとSQLの両方で）大幅に高速化され、そしてはるかに気難しいと展開が困難
。 パフォーマンスが要因である場合は、、私はDBXで行くと思います。そうでなければ、私は簡単のためADOを使用すると思います。
は、DBXは、特定の場合に、または特定の状況下で生パフォーマンスのエッジを有していてもよいが、ADOの性能が比較的劣ることができるがので、ADOは、世界におけるアプリケーションの非常に大きな数のための基礎でありますそれは「許容できないほど」不良というわけではありません。
自分のため、そして私が働いている主要なプロジェクトによって知らされ、DBXの最大の「問題」は、それがいかに良い関係なく、それは言語/ツール会社が提供する重要な基盤技術であるということです。
前のBDE技術上のアプリケーションを構築し、誰でもその技術は廃止され、もはやサポートされている場合に生じる混乱を証明します。何の技術がそれのプロバイダによって廃止を免れるされていない一方で、それはテクノロジー・プロバイダー自身を超えて産業支援に来るとき、ADOは明らかにエッジを持っています。
そのために私自身は今、常にADOを使用します。ただ、接続文字列を変更すると、常にしかし別のデータベースタイプから変更したときに心配する唯一のものではありません。ストアドプロシージャの呼び出し構文は、別のADOプロバイダから変えることができ、あなたはまだあなたがSQLサポートは別の異なる場合があり、複数の異なるSQLエンジン、反対展開予定の場合は、使用するSQL構文を見ている。
私はADOオブジェクトモデルの私自身のカプセル化を使用してこれらの問題を軽減するために。このカプセル化は、ADO似ていない何かにオブジェクト・モデルを変異しようとしません、それは単に私がもっとObjectPascalとフレンドリー（および「タイプ」安全）の形（例えば列挙型の中で直接使用する必要がありますADOのそれらの部分を露出させ、定数やフラグ等のためのセットではなく、単にスコアならない整数の定数の数百）。
私のカプセル化はまた、このようなストアドプロシージャの呼び出し構文では、前述の違いなど、さまざまなプロバイダーの行動/要件、中に小さな変化のいくつかの世話をする。
私はまた別のポスターへの同様の言うべき、私は長すぎる前に、このアプローチを切り開く使用される「データ認識コントロール」を、停止しました。あなたが必要とするか、またはデータに認識コントロールを使用したいとADOを使用したい場合は、直接ADOを使用することはできませんし、代わりにVCLデータセットモデルを通してADOを公開するいくつかのカプセル化を見つける必要があります。
ADOは、Microsoftの世界である。
DBXは、クロスプラットフォームの開始（デルファイ6）で作成し、Kylixの
