Database 使用Delphi的ADO或DBX

从Delphi Win32应用程序（ADO或DBX（Database Express））连接到MS SQL、Oracle或Firebird时，使用哪个更好（出于什么原因）

两者都允许您连接到主要数据库。我喜欢ADO通过改变连接字符串来完成这一切的方式，而且事实上，ADO和驱动程序都包含在Windows中，因此没有额外的部署（看起来，如果我错了，请纠正我）

DBX也很灵活，我可以将驱动程序编译到我的应用程序中，不是吗

如果可能的话，我非常希望有一个单一的来源，能够根据客户的IT部门/偏好改变数据库

但哪一个更容易编程、性能更好、使用内存效率最高？还有什么能让他们与众不同的吗

---

谢谢，Richard

ADO使用简单，并且在那里，您只需确保在客户端安装相应的客户端驱动程序

我发现DBX更灵活，它更好地集成在IDE和其他技术（如DataSnap）中

出于与您相同的目的，我使用了来自的第三方驱动程序的DBX。

---

如果您购买了驱动程序源代码，您可以使用应用程序编译驱动程序。

一般规则：每一层组件都可能会添加一层额外的bug。ADO和DBX都是围绕标准数据库功能的组件包装器，因此它们同样强大。 因此，正确的选择应该基于其他因素，比如您想要使用的数据库。如果您想连接到MS Access或SQL Server，ADO将是更好的选择，因为它更适合这些数据库。但是Firebird和Oracle对于DBX组件来说更为原生

不过，我个人倾向于使用原始ADOAPI。再说一次，我在项目中不使用数据感知组件。我知道，它没有那么红。但我经常需要这样做，因为我通常在数据库和GUI之间编写多层客户机/服务器应用程序，从而使事情变得更复杂。

ADO是Microsoft world

---

DBX是在一开始（Delphi 6）为跨平台和Kylix创建的：DBX速度明显更快（在oracle和sql上），而且更挑剔，更难部署

---

如果性能是一个因素，我会选择DBX。否则，为了简单起见，我只会使用ADO。

正如其他人所说，在某些情况下或特定情况下，DBX在原始性能方面可能具有优势，但ADO是世界上大量应用程序的基础，因此尽管ADO的性能可能相对较差，但这显然并不意味着“不可接受”可怜的

就我自己而言，从我所从事的主要项目来看，DBX最大的“问题”是，无论它有多好，它都是一家语言/工具公司提供的关键基础设施技术

任何在以前的BDE技术上构建应用程序的人都将证明该技术被弃用且不再受支持时所造成的中断。虽然没有一种技术可以免受其提供商的抨击，但ADO在技术提供商自身之外的行业支持方面显然具有优势

出于这个原因，我自己现在总是使用ADO。但是，在从一种数据库类型更改为另一种数据库类型时，更改连接字符串并不总是唯一需要担心的事情。存储过程调用语法可能因ADO提供程序而异，如果您打算针对多个不同的SQL引擎进行部署，则仍然需要注意所使用的SQL语法，其中SQL支持可能因时间而异

为了缓解这些问题，我使用自己的ADO对象模型封装。这种封装并不试图将对象模型变为与ADO不同的东西，它只是以更为ObjectPascal友好（且“类型”安全）的形式（例如枚举类型、常量和标志集等）直接公开ADO的那些部分，而不是分数（如果不是数百个整型常量的话）

我的封装还考虑了不同提供者行为/需求中的一些细微变化，例如前面提到的存储过程调用语法的差异

---

我还应该说，与另一张海报类似，我很久以前就停止使用“数据感知控件”，这开启了这种方法。如果您需要或希望使用数据感知控件并希望使用ADO，那么您不能直接使用ADO，而必须找到通过VCL数据集模型公开ADO的封装。

在Delphi的开始，人们称赞Delphi中的多DBMS支持。每个人都喜欢BDE（因为这是唯一的方法）

但在过去十多年中，我观察了客户，发现他们的应用程序中对多DBMS的支持在稳步下降

从一个应用程序支持多个DBMS的成本很高

不仅因为您必须了解每个DBMS，还因为每个DBMS都有自己的一组特殊性，您必须在数据访问层中适应这些特殊性。这不仅包括语法和底层数据类型的差异，还包括优化策略

另外，有些DBMS使用ADO工作得更好，有些使用直接连接（比如一起跳过Oracle客户机）工作得更好

最后，使用多个DBMS系统测试软件的所有组合是非常密集的

我参与过几个项目，其中我们必须更改DBMS后端和/或数据访问技术（即从BDE更改为DBX，或从DBX更改为直接连接）。改变后端总是比改变数据访问技术痛苦得多。多层方法使它们变得更容易，但增加了自由度，从而增加了测试工作

我看到的一些支持多DBMS的产品是在垂直市场应用程序中，其中