|
|
|
| XP is just a number | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
Module(s):
Author(s):
This is a short review of the two most used Perl toolkits for retrieving data from an Oracle database, DBI and Oraperl. In the beginning, there was Oraperl, and if you were using Perl 4, Oraperl was the only game in town. Then came Perl 5, then DBI. Now every RDBMS worth using has a uniform interface for Perl. But...what to do with all that old Oraperl code? Re-write?, /dev/null?, keep it?
The Oraperl module (originally written by Kevin Stock) was re-written for Perl 5 by Tim Bunce to use the DBD::Oracle interface. So you get the best of both worlds...backward compatability for your existing scripts, and a new API to utilize in case you desire a generic interface that could perhaps work against another DBI supported RDBMS. On the job, I use both. I support a web-based HR system that was written originally in Perl 4 using Oraperl. This codebase now is on Perl 5, however the scripts still utilize Oraperl. So for new development I use DBD::Oracle via DBI, and when maintaining existing scripts I keep using Oraperl. When first taking over this position, I was convinced that I would need to eventually remove all that damn Oraperl....then I read the perldoc, and realized that this was not the same Oraperl I used about 4 years previous in another life, but one written and supported by the very man who wrote and supported DBI and DBD::Oracle...Tim Bunce. So instead of spending time re-writing boatloads of working code, I spent some time using Benchmark and attempted to see if there was any significant performance differences in using DBD:Oracle directly, or using the Oraperl interface to it. My benchmarks all proved out to me that Oraperl was in fact slower....just barely. In fact, they were so close in my tests that I just have no valid performance reasons to rework any Oraperl into native DBI. So which to use for accessing your Oracle database? Since Tim mentions in the docs that Oraperl is for backward compatibility, I suggest that you do not <cite>use Oraperl;</cite> if you are starting fresh. If you have existing code and are curious to the benefits of porting the code to native DBI...that's your call, I found no performance reasons for doing so, and since the same man that supports DBI wrote Oraperl, there shouldn't be any pressing issues over support. Bottom line is that both these modules are of high quality and production-ready, you can be safe utilizing either. For this review, I have decided to not supply any code samples as Tim Bunce has provided plenty of them in the perldocs. So if you are curious about syntactical and/or other differences....please refer to these links:
In reply to DBI vs. Oraperl by wardk
|
|