Re[2]: [PHP-PEAR] PHPLib and Pear merge
[email protected] (Maxim Derkachev) Fri, 9 Mar 2001 16:07:21 +0300
| Newsgroups | php.pear |
|---|---|
| Organization | Symbol Plus Publishing Ltd. |
| Message-ID | <[email protected]> |
Hello Chuck, Wednesday, March 07, 2001, 7:22:27 PM, you wrote: >> Could you elaborate upon this limitation with a simple example of what you >> can't do with phplib and what you can do with PEAR:DB? CH> If I want to nest sql queries, such that each inner query depends on a row of CH> the outer query, I can do this in pear, because running a new query doesn't CH> wipe away the current result set. But with phplib, I'd need to loop through the CH> entire outer query, store the results somewhere, and then do all of the inner CH> queries. Valid point, but you are not telling the whole truth. You know that you can initialize another DB_Sql object within the loop. It would act like a PEAR::DB result object. Since PHP reuses connections, the script actually won't do any extra connect()s to execute the nested query. DB_SQL is light and even in this condition it should run faster then the huge PEAR::DB structure. So you indeed *can* do the thing easily. PEAR::DB, instead do have some crucial limitations in its current state. E.g. why don't bother to include support for accessing number of rows affected by the insert/update/delete query? It is supported by almost any mainstream database available. Why don't bother to count number of rows returned by select? It is one of most needed things in web development. It is natively supported by many databases (e.g. Mysql, Postgres), and can be easily emulated (or, in any case, the method could return 'not supported' for performance reasons) for those that don't support this. PEAR::DB eats much more resources then DB_Sql and can't afford those simple things which could be done in half an hour or less? -- Best regards, Maxim Derkachev mailto:[email protected] Symbol-Plus Publishing Ltd. phone: +7 (812) 324-53-53 http://www.Books.Ru -- All Books of Russia