我不知道使用一个相对于另一个有什么优点和缺点。这个问题源自我在这里得到的建议：根据记录的实际大小为数据库查询动态分配缓冲区。 我正在寻找重要差异的列表（而不是详尽的列表），这将有助于我做出有根据的决策。我有win32 :: odbc的工作经验，可以对此进行真正的证明。如果有人可以在“书面”详细信息的基础上分享他/她的经验，那将非常有帮助。
附加信息：Win32 :: ODBC的作者在此处写道：http : //www.roth.net/perl/odbc/docs/ODBC_Docs.htm- “可以使用Win32 :: ODBC的几种替代方法，例如数据库接口（ DBI）版本，称为DBD :: ODBC。此ODBC Perl扩展可在Mac和UNIX等不同平台上使用，尽管缺少Win32 :: ODBC的某些功能，但它还是用于ODBC访问数据库的好工具。 ” 我想知道您是否知道它缺少的功能。
我选择DBI堆栈的主要原因是灵活性和广泛的测试人员/调试人员。这样一来，DBI您就可以选择使用特定于您的特定数据库引擎的驱动程序。是的，大多数数据库还提供ODBC驱动程序，但是某些特定功能可能无法使用，或者通过该特定API更加麻烦。此外，它DBI是独立于平台的，因此将来任何可能的移植到另一个OS的麻烦都大大减少了。最后，DBI用于数据库访问的人员数量 远远 超过了使用的人员Win32::ODBC，这意味着可能会更快地发现并修补错误。
DBI
Win32::ODBC
在查看另一个链接的问题时，我注意到您正在使用Oracle。使用时，DBI您可以选择在内部使用DBD::ODBC还是DBD::Oracle在内部使用。您可以通过简单地更改DBI->connect方法的参数之一来进行选择。
DBD::ODBC
DBD::Oracle
DBI->connect
如果使用的是Oracle Instant Client，则使用DBD::Oracle可以节省在仅需要通过Perl进行访问的计算机上下载/安装ODBC组件的麻烦。当然，从等式中删除ODBC层也可能有好处。
更新 ：Win32 :: ODBC是ODBC中间件API从C到Perl的相对直接转换。如果您愿意将自己限制为Windows上的ODBC连接，那么这样做确实具有相对较小的优势，即可以直接控制正在控制基础数据库的ODBC中间件层。当然，这并不意味着ODBC API特别忠实于基础数据库的API和/或功能。
同样，假设您使用的是Oracle，您似乎有3种选择：
“〜>”位于需要“填充”一个API以适合另一个API的层的右侧。
现在，我可以理解，如果您发现对ODBC中间件的API保真度是理想的。就个人而言，我宁愿具有DBI＆所使用的较短软件堆栈的灵活性DBD::Oracle。尽管我还会猜测DBD::ODBC，即使使用两个垫片层，涉及的较长堆栈也可以满足所有需求的99％以上。
DBI＆之间的另一个区别Win32::ODBC是，围绕堆栈构建了 许多 模块DBI。整个DBIx命名空间都取决于它。在metacpan.org上搜索每个模块，然后单击其页面上的“反向依赖关系”链接，您将清楚地看到Perl社区为每个模块分配的相对价值。
DBIx
因此，如果您需要其他纯粹自私的理由：具有DBI经验的Perl开发人员也将发现自己 有 更大的需求。严重地。
