3

我想知道使用其中一个的优点和缺点是什么。这个问题源于我在这里得到的一个建议：根据记录的实际大小为数据库查询动态分配缓冲区
我正在寻找一个重要差异的列表（而不是一个详尽的列表），这将帮助我做出有根据的决定。我有使用 win32::odbc 的工作经验，可以真实地证明这一点。如果有人可以在“枯燥”的记录细节之上分享他/她的经验，那将非常有帮助。

附加信息：Win32::ODBC 的作者在这里写道：http ://www.roth.net/perl/odbc/docs/ODBC_Docs.htm -“Win32::ODBC 有几种替代方案，例如数据库接口（ DBI) 版本称为 DBD::ODBC。此 ODBC Perl 扩展可用于不同平台，例如 Mac 和 UNIX。它是用于 ODBC 访问数据库的好工具，尽管它缺少 Win32::ODBC 具有的一些功能。 " 我想知道您是否知道它缺少什么功能。

4

1 回答 1

4

我选择堆栈的主要原因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 的 ODBC 驱动程序 ~> Oracle 客户端 -> Oracle 服务器
  • DBI-> DBD::Oracle~> 甲骨文客户端 -> 甲骨文服务器
  • DBI-> DBD::ODBC~> ODBC -> Oracle's Driver for ODBC ~> Oracle Client -> Oracle Server

'~>' 位于需要“填充”一个 API 以适应另一个 API 的层的右侧。

现在我可以理解您是否认为对 ODBC 中间件的 API 保真度是可取的。就个人而言，我宁愿DBI拥有DBD::Oracle. 虽然我也猜测更长的堆栈涉及DBD::ODBC将满足所有需求的 99% 以上，即使有两个垫片层。

DBI&之间的另一个区别Win32::ODBC是围绕堆栈构建了许多模块。DBI整个DBIx命名空间都依赖于它。在 metacpan.org 上搜索这些模块中的每一个，然后单击其页面上的“反向依赖关系”链接，您将清楚地了解 Perl 社区为每个模块分配的相对价值。

因此，如果您想要一个额外的、纯粹自私的理由：具有 DBI 经验的 Perl 开发人员也会发现自己的需求量更大。严重地。

于 2014-09-24T18:52:14.153 回答