These 'benefits' you talk about really only matter if you switch your databases. If this app is written against Oracle and they never plan to change it, then it isn't a bad idea to cut out that fat and just deal with the native interface. Even writing wrapper functions that are very basic that abstract mysql_query or mssql_query end up adding a lot of overhead over lots of requests. Look at some of the PDO benchmarks. It is slower than the native functions too because it is just a wrapper.
Using native functions all over the place, how would you log all the database queries that a page is running (especially if you don't have server-level access, only ftp access - ie a clients server on a shared host) ?
Using wrapper functions/classes it's easy to add an error_log call in to the 'Query' method to see where everything comes from, and/or how long each query takes to run.
Obviously that stuff is disabled by default but with a code change it's doing what you need.
Even further if you are writing an app where you care about performance you should be writing your SQL to the point where it really isn't portable using all the little vendor specific features so that you get the most out of it.
Depends on the app I guess, though I haven't seen an app that vendor specific (apart from anything to do with full text searching).
Using xdebug is the first step to working out where your real bottleneck is - I highly doubt it'll be the wrapper class/functions.
-- Postgresql & php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
