On Mon, Mar 3, 2008 at 9:21 PM, Chris <dmagick@xxxxxxxxx> wrote: > > > 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/ > He said he can't use xdebug. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
