问题
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.
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.
回答1:
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.
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.
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.
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.
Again, presuming that you're using Oracle, you seem to have 3 choices:
Win32::ODBC-> ODBC -> Oracle's Driver for ODBC ~> Oracle Client -> Oracle ServerDBI->DBD::Oracle~> Oracle Client -> Oracle ServerDBI->DBD::ODBC~> ODBC -> Oracle's Driver for ODBC ~> Oracle Client -> Oracle Server
Where the '~>' is to the right of a layer that needed to "shim" one API to fit another.
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.
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.
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.
来源：https://stackoverflow.com/questions/26022754/dbdodbc-vs-win32odbc