我选择DBI 堆栈的主要原因是灵活性和更广泛的测试人员/调试人员。使用DBI，您可以选择使用专门针对您的特定数据库引擎调整的驱动程序。是的，大多数数据库还提供 ODBC 驱动程序，但某些特定功能可能无法通过该特定 API 获得或更麻烦。此外，DBI 是独立于平台的，这使得将来任何可能的移植到另一个操作系统的麻烦都会大大减少。最后，使用DBI 进行数据库访问的人数远超过了使用Win32::ODBC 的人数，这意味着可以更快地发现和修补错误。
查看您的其他链接问题，我注意到您正在使用 Oracle。使用DBI，您可以选择在后台使用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 个选择：
-
Win32::ODBC -> ODBC -> Oracle's Driver for ODBC ~> Oracle Client -> Oracle Server
-
DBI -> DBD::Oracle ~> Oracle 客户端 -> Oracle 服务器
-
DBI -> DBD::ODBC ~> ODBC -> Oracle 的 ODBC 驱动程序 ~> Oracle 客户端 -> Oracle 服务器
“~>”位于需要“填充”一个 API 以适应另一个 API 的层的右侧。
现在我可以理解您是否认为 API 忠实于 ODBC 中间件是可取的。就个人而言，我宁愿拥有DBI 的灵活性和DBD::Oracle 使用的更短的软件堆栈。虽然我也猜测涉及DBD::ODBC 的较长堆栈将满足所有需求的 99% 以上，即使有两个垫片层。
DBI 和Win32::ODBC 之间的另一个区别是有许多 模块围绕DBI 堆栈构建。整个DBIx 命名空间都依赖于它。在 metacpan.org 上搜索这些模块中的每一个，然后单击其页面上的“反向依赖”链接，您将清楚地了解 Perl 社区赋予每个模块的相对价值。
因此，如果您想要一个额外的、纯粹自私的理由：具有 DBI 经验的 Perl 开发人员也会发现他们对自己的需求要大得多。认真的。