DBI是在Perl中访问数据库的唯一方法吗？
除了DBI之外是否还有其他包装可用于访问MS-SQL/Oracle/MySQL等数据库。
答案 0 :(得分：5)
暂时，尝试在 Windows之前想象个人电脑的硬件市场。例如，在那些日子里，每个应用程序都需要有自己的驱动程序。这意味着如果打印机没有WordStar和Lotus 1-2-3的驱动程序，那么在办公环境中它几乎没用。如果您的打印机可以同时使用这两个应用程序，但您现在也需要Harvard Graphics的输出，该怎么办？您需要确保应用程序本身知道如何处理您的特定打印机。
也就是说， N 应用程序和 M 打印机意味着需要 N × M 驱动程序。
使用Windows，硬件制造商可以为Windows编写驱动程序，只要应用程序知道如何通过Windows提供的界面与打印机通信，就不需要了解有关特定硬件的任何信息。
这使得硬件和软件都更便宜。具体而言，应用程序员不需要了解存在的特定硬件。并且，如果应用程序通过相同的驱动程序接口进行通信，那么在编写应用程序时不存在的硬件仍然可以与应用程序一起使用。
当然，这是一个相当简化的情况。即使使用DOS，也有ESC/P，PCL，当然还有PostScript，所以它并不像每台打印机都是独一无二的，但应用程序仍然需要注意这样的细节。
这里的情况类似。知道如何与DBI通信的Perl应用程序，大多数情况下，不必关心每个特定数据库的大多数细节。使特定数据库可用于Perl程序只需要为其编写适当的DBD::*模块。 DBI documentation中的下图说明了这一点：
|<- Scope of DBI ->|
.-. .--------------. .-------------.
.-------. | |---| XYZ Driver |---| XYZ Engine |
| Perl | | | `--------------' `-------------'
| script| |A| |D| .--------------. .-------------.
| using |--|P|--|B|---|Oracle Driver |---|Oracle Engine|
| DBI | |I| |I| `--------------' `-------------'
| API | | |...
|methods| | |... Other drivers
`-------' | |...
`-'
一旦DBI存在，就会减少为给定引擎编写或使用特定专用模块的动机。当然，让独立模块与某处ABC引擎单独通信可能会有一些好处，但这些好处必须与成本进行权衡。应用程序需要数据库访问的程序员需要了解不熟悉的API的细节。如果访问ABC引擎的唯一方法是通过DBI之外的其他方式，则ABC引擎不允许程序员利用他们已经知道的内容。使用ABC引擎专用API的应用程序无法与其他引擎一起使用，或者应用程序程序员必须使用自己的数据库独立接口，并对其进行编程，并将DBD复制到{{ 1}}层。但是，当已经存在已建立的数据库独立接口及其附带的数据库驱动程序时，为什么还要烦恼呢？
看看DBIx::Class的引擎特定部分，想象一下，如果我们没有为每个引擎提供DBI，那将会有多少工作。然后，假设Rose::DB还必须复制整套驱动程序。
或者，您可以想象如果每个房子都有其首选类型的墙壁插座并且每个设备都有自己的首选电源插头会发生什么。每台笔记本电脑都有自己的变压器，但我们都可以从标准的插头和插座中受益，它们可以从中获取电力。 DBD处于插件级别。