数据库连接Delphi

我曾在许多使用ADO的商业大容量系统上工作过,没有任何问题。部署相对简单,因为它包含在操作系统中。由于它拥有如此广泛的受众,因此大多数主要问题都得到了识别和纠正。获取有关ADO连接的帮助非常容易。数据库支持很深( connectionstrings.com )这使得支持额外的数据库引擎变得非常简单(您可能仍然需要安装客户端驱动程序,但对于几乎所有的解决方案来说都是一样的)。

性能并不是什么大问题,它真的将取决于数据库体系结构和引擎选择。

@Arthurprs,为你设想

(2层)5台用户计算机,1台数据库服务器。

alt text http://www.techsolusa.com/images/firebird-logo-64.gif 这个 Firebird RDBMS是一个很好的选择,因为它非常稳定、快速,可以在Linux、Windows和各种UNIX平台上运行,并满足您的需求。

alt text http://d.yimg.com/kq/groups/12858579/homepage/name/homepage.jpg 关于我要连接的组件 ZEOS .

我在许多中小型项目中使用了这种组合,效果非常好。

我不得不说我很高兴 NexusDB 但是客户机/服务器版本的成本可能不值得。

它可以在客户端/服务器上工作,或者完全嵌入,非常简单,您可以在应用程序中同时使用它们,并根据客户的需要在它们之间进行切换。

• 嵌入式数据库是免费的,
• 客户端/服务器“按开发人员定价”是 AU$ 500
• 每次安装不收费。

哦,是的,它是用德尔菲写的;)

我想说,与Firebird一起使用-是Delphi领域最常用的数据库引擎(参见 here )对于连接性,最好使用Zeos(免费)或DBX(如果您能负担得起架构师版本——唯一一个拥有Firebird驱动程序的版本)。

关于ADO:成熟的连接层,但它将(永远-最可能)绑定到Windows,而Delphi将跨平台。而且,是的,由于许多原因,它往往是较慢的,包括在某些情况下使用的ODBC驱动程序。但在你的情况下,当然,正如斯卡姆拉特所说,我没有 认为 这将非常重要。

虽然我读过一些人不喜欢将两者混合的想法,但我已经将ADO数据集用作“提供者层”,然后将数据输入到TClientDataSets中,取得了很好的效果——因此,如果您在ADO路线上发现需要客户端数据集(它们很有用),那么就没有理由不能使用客户端数据集。

否则,我会附和这样的评论:ADO是一个经过尝试的、可信的机制,它不会出现在任何地方。我发现它总是够快的。使用UDL文件进行配置是很好和容易的。

• dbgo(ado)更易于管理、更通用、更慢
• DBExpress更快速、更复杂,支持的DBMS更少
• zeosdbo易于管理,通用的类似dbexp,慢的类似dbgo,跨平台的,有很少的附加组件,所有的源都是可访问的

其他图书馆很少,解决了上述所有疑问,尽管它们都是商业产品。但我有偏见:)

我们在中型数据库应用程序中使用了使用devart pg组件的PostgreSQL。 我们用这个组合做了一些有限的基准测试,发现它是使用ADO的速度的2-3倍。

--数据访问组件

我也赞成tclientdataset和ADO的组合。我可以说这是值得信赖的。TClientDataSet的灵活性是一个巨大的收益。DBExpress也不错。 实际上,我使用的客户端数据集几乎所有的数据访问层都有TDataset子代…

--服务器

火鸟。从OLEDB(我和ODBC一起使用)和DBExpress(D2010+有本机DBX驱动程序)中免费且容易使用-不知道Zeos,但我相信它也可以连接到FB。 可以很好地扩展到许多连接和大型数据库。Firebird上有500GB的数据库,有很多用户报告。