使用 Delphi 的 ADO 或 DBX
从 Delphi Win32 应用程序连接到 MS SQL、Oracle 或 Firebird，ADO 或 DBX (Database Express) 哪个更好（以及出于什么原因）？
两者都允许您连接到主要数据库。我喜欢 ADO 通过更改连接字符串来完成这一切的方式，而且 ADO 和驱动程序包含在 Windows 中，因此不需要额外部署（看起来，如果我错了，请纠正我）。
DBX 也很灵活，我可以将驱动程序编译到我的应用程序中，不是吗？
如果可能的话，我真的很希望拥有单一来源，并且能够根据客户的 IT 部门/偏好来改变数据库。
但哪个更容易编程、性能更好、使用内存最有效？还有其他什么可以区分它们吗？
谢谢，理查德
Which is better (and for what reasons) to use to connect to MS SQL, Oracle or Firebird from a Delphi Win32 application -- ADO or DBX (Database Express)?
Both allow you to connect to the major databases. I like the way ADO does it all with a connection string change and the fact that ADO and the drivers are included with Windows so nothing extra to deploy (it seems, correct me if I'm wrong).
DBX is also flexible and I can compile the drivers into my app, can I not?
I really am keen to have a single source if possible, with the ability to vary databases depending on the customer's IT department/preferences.
But which is easier to program, performs better, uses memory most efficiently? Any other things to differentiate them on?
Thanks, Richard
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
ADO使用简单，只要在客户端安装相应的客户端驱动程序即可。
我发现 DBX 更灵活，并且可以更好地集成到 IDE 和 DataSnap 等其他技术中。
出于与您相同的目的，我将 DBX 与来自 DevArt 的第三方驱动程序一起使用。
如果您购买驱动程序源，则可以使用您的应用程序编译驱动程序。
ADO is simple to use and is there, you only must make sure to install the correponding client driver in the client side.
I found DBX more flexible and it is better integrated within IDE and another technologies like DataSnap.
For the same purpose than you, I have used DBX with Third Party Drivers from DevArt.
You can compile the drivers with your application if you buy the drivers sources.
在Delphi诞生之初，人们就称赞Delphi对多DBMS的支持。每个人都喜欢 BDE（因为这是做到这一点的唯一方法）。
但是，当我观察过去十年的客户时，我发现他们的应用程序中对多 DBMS 的支持不断减少。
从一个应用程序支持多个 DBMS 的成本很高。
不仅因为您必须了解每个 DBMS，还因为每个 DBMS 都有其自己的一组特性，您必须在数据访问层中适应这些特性。这些不仅包括语法和底层数据类型的差异，还包括优化策略。
此外，有些 DBMS 与 ADO 配合使用效果更好，有些则与直接连接配合使用效果更好（例如完全跳过 Oracle 客户端）。
最后，测试软件与多个 DBMS 系统的所有组合是非常密集的。
我参与过一些项目，在这些项目中我们必须更改 DBMS 后端和/或数据访问技术（从 BDE 到 DBX，或从 DBX 到直接连接）。改变后端总是比改变数据访问技术要痛苦得多。多层方法使它们变得更容易，但增加了自由度，从而增加了测试工作量。
我确实看到一些支持多 DBMS 的产品位于垂直市场应用程序中，其中最终客户已经拥有自己的 DBMS 基础设施，并且应用程序需要适应这一点。例如在荷兰政府领域，Oracle 非常强大，但 SQL Server 也建立了相当大的用户基础。
因此，您需要考虑要支持哪些 DBMS 组合，不仅要考虑功能，还要考虑成本。
如果您坚持使用一种 DBMS，那么采用 BDE、DBX 或 ADO 等通用数据访问层就没有意义：尽可能直接进行连接是值得的。
我的经验告诉我，这些组合效果很好：
Microsoft SQL Server 与 ADO
希望这能让您了解从 Delphi 应用程序支持多个 DBMS 的可能性和局限性。
——杰罗恩
In the beginning of Delphi, people praised the multi-DBMS support in Delphi. Everyone loved the BDE (because that was the only way to do that).
But when looking at customers over more then the past decade, I have seen a steady decrease of multi-DBMS support in their applications.
The cost of supporting multiple DBMS from one application is high.
Not only because you have to have knowledge of each DBMS, but also because each DBMS has its own set of pecularities, where you have to adapt for in your data access layer. These not only include differences in syntax and underlying data types, but also optimization strategies.
Also, some DBMS work better with ADO, some better with a direct connection (like skipping your Oracle client all together).
Finally testing all the combinations of your software with multiple DBMS systems is very intensive.
I've been involved in a few projects where we had to change the DBMS backend and/or the data access technology (from i.e. BDE to DBX, or from DBX to a direct connection). Changing the backend always was much more painfull than changing the data access technology. Multi-tier approaches made them somewhat easier, but increased the degrees of freedom and therefor the testing efforts.
Some of products that I do see that support multi-DBMS are in vertical market applications where the final customer already has their own DBMS infrastructure and the application needs to adapt to that. For instance in Dutch governmental areas, Oracle has been really strong, but SQL Server has established quite a user base as well.
So you need to think about what combinations of DBMS you want to support, not only in terms of functionality, but also in terms of cost.
If you stick to one DBMS, then it makes no sense to go for a generic data access layer like BDE, DBX or ADO: it pays off doing a connection as direct as possible.
My experience has taught me that these combinations do work well:
Microsoft SQL Server with ADO
Hope this gives you some insight in the possibilities and limitations of supporting multiple DBMS from your Delphi applications.
--jeroen
一般规则：每一层组件都可能会增加一层额外的错误。 ADO 和 DBX 都是标准数据库功能的组件包装器，因此它们都同样强大。
因此，正确的选择应该基于其他因素，例如您要使用的数据库。如果您想连接到 MS-Access 或 SQL Server，ADO 将是更好的选择，因为它更适合这些数据库。但 Firebird 和 Oracle 更适合 DBX 组件。
不过，我个人倾向于使用原始 ADO API。话又说回来，我不在我的项目中使用数据感知组件。我知道，它不那么 RAD。但我经常需要以这种方式工作，因为我通常编写客户端/服务器应用程序，在数据库和 GUI 之间有多个层，从而使事情变得更加复杂。
General rule: every layer of components will possibly add an additional layer of bugs. Both ADO and DBX are component wrappers around standard database functionality, thus they're both equally strong.
So the proper choice should be based on other factors, like the databases that you want to use. If you want to connect to MS-Access or SQL Server, ADO would be the better choice since it's more native for these databases. But Firebird and Oracle are more native for the DBX components.
I personally tend to use the raw ADO API's, though. Then again, I don't use data-aware components in my projects. It's less RAD, I know. But I often need to work this way because I generally write client/server applications with several layers between the database and the GUI, thus making things more complicated.
我的两点意见是：DBX 明显更快（在 Oracle 和 sql 上），并且更加挑剔且更难部署。
如果性能是一个因素，我会选择 DBX。否则，为了简单起见，我只会使用 ADO。
My two cents: DBX is significantly faster (on both oracle and sql), and significantly more finicky and harder to deploy.
If performance is a factor, I'd go with DBX. Otherwise, I'd just use ADO for simplicity's sake.
正如其他人所说，在某些情况下或特定情况下，DBX 可能在原始性能方面具有优势，但 ADO 是世界上大量应用程序的基础，因此尽管 ADO 的性能可能相对较差，但显然这并不意味着意思是“穷得令人无法接受”。
对我自己来说，根据我参与过的主要项目，DBX 最大的“问题”是，无论它有多好，它都是语言/工具公司提供的关键基础设施技术。
任何在以前的 BDE 技术上构建应用程序的人都会证明该技术被弃用且不再受支持时所造成的破坏。虽然没有任何技术能够免受其提供商的弃用，但在技术提供商本身之外的行业支持方面，ADO 显然具有优势。
因此我自己现在总是使用 ADO。然而，从一种数据库类型更改为另一种数据库类型时，仅更改连接字符串并不总是唯一需要担心的事情。存储过程调用语法可能因 ADO 提供程序而异，如果您打算针对多个不同的 SQL 引擎进行部署，那么您仍然需要注意所使用的 SQL 语法，其中 SQL 支持可能因不同而异。
为了缓解这些问题，我使用了我自己的 ADO 对象模型封装。这种封装并不试图将对象模型转变为与 ADO 不同的东西，它只是公开了我需要以更加 ObjectPascal 友好（和“类型”安全）的形式直接使用的 ADO 的那些部分（例如枚举类型和设置常量和标志等，而不仅仅是分数（如果不是数百个整数常量）。
我的封装还考虑了不同提供者行为/要求中的一些细微变化，例如前面提到的存储过程调用语法的差异。
我还应该说，与另一张海报类似，我很久以前就停止使用“数据感知控件”，这开启了这种方法。如果您需要或希望使用数据感知控件并希望使用 ADO，那么您不能直接使用 ADO，而必须找到一些通过 VCL 数据集模型公开 ADO 的封装。
As others have said, DBX may have the edge in raw performance in certain cases or under specific circumstances, but ADO is the basis for a very larger number of applications in the world so although performance of ADO may be relatively poorer, clearly that does not mean "unacceptably" poor.
For myself, and informed by major projects I have worked on, the biggest "problem" with DBX is that no matter how good it may be, it is a key infrastructure technology provided by a language/tools company.
Anyone that built applications on the previous BDE technology will testify to the disruption caused when that technology is deprecated and no longer supported. Whilst no technology is immune from deprecation by it's provider, ADO clearly has the edge when it comes to industry support beyond the technology provider themselves.
For that reason I myself now always use ADO. Just changing the connection string isn't always the only thing to worry about when changing from one database type to another however. Stored procedure call syntax can vary from one ADO provider to another, and you still have to watch the SQL syntax you use if you intend deploying against multiple different SQL engines, where the SQL support may vary from on to another.
To mitigate these issues I use my own encapsulation of the ADO object model. This encapsulation does not attempt to mutate the object model into something that doesn't resemble ADO, it simply exposes those parts of ADO that I need to use directly in a more ObjectPascal friendly (and "type" safe) form (e.g enum types and sets for constants and flags etc, rather than just scores if not hundreds of integer constants).
My encapsulation also takes care of some of the minor variations in different provider behaviours/requirements, such as the previously mentioned differences in stored procedure call syntax.
I should say also that similar to another poster, I too long ago stopped used "data aware controls", which opens up this approach. If you need or wish to use data aware controls and wish to use ADO, then you cannot use ADO directly and must instead find some encapsulation that exposes ADO thru the VCL dataset model.
ADO是微软世界
DBX之初创建的（Delphi 6），用于跨平台和Kylix
ADO is Microsoft world
DBX was created at the beginning (Delphi 6) for cross platform and Kylix