Re: [metabase-dev] RE: [PEAR-DEV] Re: [binarycloud-dev] FW: lets talk "metapear" - politics aside:-)

From: Date: Mon, 18 Mar 2002 09:40:28 +0000
Subject: Re: [metabase-dev] RE: [PEAR-DEV] Re: [binarycloud-dev] FW: lets talk "metapear" - politics aside:-)
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-5012@lists.php.net to get a copy of this message
On Sun, 2002-03-17 at 21:25, Lukas Smith wrote: > > Could someone explain to me the real advantage behind prepare? > I think I know part of it but could someone just give me an entire run > down? :-) I'll give you the ones I can think of right now. For lazy programmers: If you don't want to bother with quoting, prepare is really nice. You don't have to bother about calling quote functions etc, and ease of use is one of PEAR DB's primary goals. Repeated queries: If you want to re-run the same INSERT over and over just with different data, prepare lets you do that in a way that is _much_ more efficient on the backends that have native prepare/execute support (which is most serious databases today). It has some overhead on mysql & friends, but you still have the option of just using query() if you don't care about efficiency with other backends. Query caching: Some databases, like Oracle, have a cache of parsed and optimized queries. By using prepare(), the database will need to parse and optimize your query just once instead of every time you execute it. This can be a really big speedup. Easy LOB handling: $sth = $dbh->prepare("INSERT INTO files (contents) VALUES(&)"); $sth->execute(array("/tmp/file-with-contents")); Granted, PEAR's LOB handling leaves a lot to be desired for other backends than mysql/pgsql today, but this is the API. - Stig

« previous php.pear.dev (#5012) next »