DBD :: ODBC与Win32 :: odbc [英] DBD::ODBC vs win32::odbc

问题描述

我想知道使用一个相对于另一个有什么优点和缺点.这个问题源自我在这里得到的建议:根据记录的实际大小为数据库查询动态分配缓冲区
我正在寻找重要差异的清单(而不是详尽的清单)，这将有助于我做出有根据的决定. 我有win32 :: odbc的工作经验，可以对此进行真正的证明.如果有人可以在干燥的"详细记录的基础上分享自己的经验，那将非常有帮助.

I wonder what are the advantages and disadvantages using one over the other. This question originated from an advice I got here: Allocate buffer dynamically for DB query according to the record actual size
I am looking for a list of the important differences (and not an exhaustive list) that will help me to make an educated decision. I have working experience with win32::odbc and can testify genuinely about it. It will very helpful if someone can share his/hers experience on top of the ‘dry’ documented details.

其他信息: Win32 :: ODBC的作者在此处写道: http://www.roth. net/perl/odbc/docs/ODBC_Docs.htm -"Win32 :: ODBC有多种替代选择，例如称为DBD :: ODBC的数据库接口(DBI)版本.此ODBC Perl扩展可在不同的版本中使用平台，例如Mac和UNIX.尽管它缺少Win32 :: ODBC所具有的某些功能，但是它是用于对数据库进行ODBC访问的一个很好的工具." 我想知道您是否知道它缺少的功能.

Additional info: The author of Win32::ODBC wrote here: http://www.roth.net/perl/odbc/docs/ODBC_Docs.htm - "There are several alternatives to Win32::ODBC available such as the DataBase Interface (DBI) version called DBD::ODBC. This ODBC Perl extension is available across different platforms such as Mac and UNIX. It is a good tool to use for ODBC access into databases although it lacks some of the functionality that Win32::ODBC has." I wonder if you know what is the functionality that it lacks.

推荐答案

我选择DBI堆栈的主要原因是灵活性和广泛的测试人员/调试人员.使用DBI，您可以选择使用专门调整为特定数据库引擎的驱动程序.是的，大多数数据库还提供ODBC驱动程序，但是某些特定功能可能无法使用，或者通过该特定API更加麻烦.此外，DBI是平台无关的，这使得将来任何可能的移植到另一个OS的麻烦都大大减少了.最后，使用DBI进行数据库访问 far 的人数超过了使用Win32::ODBC的人数，这意味着可能会发现&漏洞.修补速度更快.

My main reasons with going for the DBI stack are flexibility and the broader population of testers/debuggers. With DBI you are allowing yourself the option of using a driver that is specifically tuned to your particular database engine. Yes, most databases also offer an ODBC driver, but some specific capabilities may be unavailable or more troublesome through that particular API. Additionally, DBI is platform independent, making any possible future porting to another OS that much less trouble. Lastly the population of folks using DBI for their database access far exceeds those using Win32::ODBC, meaning bugs are likely to be found & patched quicker.

看着另一个链接的问题，我注意到您正在使用Oracle.使用DBI，您可以选择在引擎盖下使用DBD::ODBC或DBD::Oracle.您可以通过简单地更改DBI->connect方法的参数之一来进行选择.

Looking at your other linked question I notice you are using Oracle. Using DBI you'd have the choice between using DBD::ODBC or DBD::Oracle under the hood. You can make this choice with a simple change to one of the parameters of the DBI->connect method.

如果使用的是Oracle Instant Client，则使用DBD::Oracle可以避免在仅需要通过Perl进行访问的计算机上下载/安装ODBC组件的麻烦.当然，从等式中删除ODBC层也可能有好处.

If you are using Oracle's Instant Client, using DBD::Oracle can save you the trouble of downloading/installing the ODBC component on machines that will only need access via Perl. Of course removing the ODBC layer from the equation may have benefits as well.

---

更新: Win32 :: ODBC是ODBC中间件API从C到Perl的相对直接转换.如果您愿意将自己限制为Windows上的ODBC连接，那么这样做确实具有相对较小的优势，即可以直接控制正在控制基础数据库的ODBC中间件层.当然，这并不意味着ODBC API特别忠实于基础数据库的API和/或功能.

---

Update: Win32::ODBC is a relatively direct conversion of the ODBC Middleware API from C to Perl. If you are willing to limit yourself to ODBC connections on Windows, this does have the relatively minor advantage of giving you more direct control of the ODBC Middleware layer that is controlling your underlying Database. This of course does not imply that the ODBC API is particularly faithful to the API and/or capabilities of the underlying Database.

同样，假设您使用的是Oracle，您似乎有3种选择:

Again, presuming that you're using Oracle, you seem to have 3 choices:

• Win32::ODBC-> ODBC-> Oracle的ODBC驱动程序〜> Oracle Client-> Oracle Server
• DBI-> DBD::Oracle〜> Oracle客户端-> Oracle Server
• DBI-> DBD::ODBC〜> ODBC-> Oracle的ODBC驱动程序〜> Oracle Client-> Oracle Server

• Win32::ODBC -> ODBC -> Oracle's Driver for ODBC ~> Oracle Client -> Oracle Server
• DBI -> DBD::Oracle ~> Oracle Client -> Oracle Server
• DBI -> DBD::ODBC ~> ODBC -> Oracle's Driver for ODBC ~> Oracle Client -> Oracle Server

〜>"位于需要填充"一个API以适合另一个API的层的右侧.

Where the '~>' is to the right of a layer that needed to "shim" one API to fit another.

现在，我可以理解，如果您希望使用ODBC中间件的API保真度是理想的.就个人而言，我宁愿具有DBI&的灵活性. DBD::Oracle使用的较短的软件堆栈.尽管我还会猜测，涉及到DBD::ODBC的较长堆栈可以满足所有需求的99％以上，即使有两个垫片层也是如此.

Now I can understand if you find API fidelity to the ODBC Middleware to be desirable. Personally, I'd rather have the flexibility of DBI & the shorter software stack used by DBD::Oracle. Though I'll also guess that the longer stack involving DBD::ODBC would suit 99+% of all needs, even with two shim layers.

DBI&之间的另一个区别Win32::ODBC是围绕DBI堆栈构建的许多模块.整个DBIx命名空间都取决于它.在metacpan.org上搜索每个模块，然后单击其页面上的反向依赖"链接，您将获得Perl社区为每个模块分配的相对价值的清晰印象.

Another difference between DBI & Win32::ODBC is that there are many modules built around the DBI stack. The entire DBIx namespace depends on it. Search for each of these modules on metacpan.org and click on the 'reverse dependencies' link on their page and you'll get a rather sharp picture of the relative value the Perl community has assigned to each.

因此，如果您想要一个额外的，纯粹自私的理由:具有DBI经验的Perl开发人员也将发现自己在更大的需求中.认真地.

So if you want an additional, purely selfish, reason: a Perl developer with experience in DBI will also find themselves in much greater demand. Seriously.

这篇关于DBD :: ODBC与Win32 :: odbc的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！