Justin Patrin wrote:
I think you're confusing the issue. PEAR DB does support many databases, but it only loads the code for the ones that you are currently using. So if you're using one database it is effectively a one database API.
Jakes wrote:
What is performance like using this class? I've gone through the class and
it just seams to be over kill, for a DB API (13 databases).
Are there any time stats showing the different time in using a single DB API
class to the PEAR class.
Yes things are really not that bad. However expect to give up somewhere a fairly significant amount of performance. If you are using an abstraction layer you have to do it with a good reason (you need to support multiple databases mainly :-) ).
Here is a benchmark John Lim came up with: http://phplens.com/lens/adodb/
It only tests MySQL though and it implements a very unrealistic scenario. The reason that ADODB scores so high can be read here:
http://marc.theaimsgroup.com/?l=pear-dev&m=100793507904834&w=2
Well, yes, you're going to lose some processing time using an abstraction layer, but IMHO the pros far outweight the cons, even if you don't need ot support multiple DBs.
1) Many very useful utility functions which will give you the data you want and automatically free resources for you, such as getRow(), getAll(), and getOne().
2) Good and easy to use error handling (this is very important, believe me).
3) A unified architecture for mysql and Oracle. You don't have to remember different functions for use with different databases.
4) You never know when you might want to switch to another DB.
5) You never know someone else using your code might want to switch to another DB.
The company I'm at now had an abstraction layer of their own (for all of these reasons) and it wasn't nearly as good as PEAR DB even after all of the work I put into it. I just didn't have the time to deal with it all on my own. I'd much rather use PEAR DB which has lots of developers working on it and using it, finding bugs and making patches. :-)
-- paperCrane <Justin Patrin>
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
