Re: PEAR DB and ADO+

"Manuel Lemos" <mlemos@acm.org> wrote in message news:3ADEEEBD.C940AF1A@acm.org... > Hello, > > John Lim wrote: > > > > Hi Manuel, > > > > Some preamble first. > > > > Many high performance dynamic websites make extensive use of caching data > > from the database in order to scale, so that a server farm can be serviced > > by one database server. > > > > In most PHP database wrapper libraries, the caching is not integrated into > > the library, but done by some other program, eg: Session variables or PEAR > > Cache. > > > > Now suppose the user is viewing the recordset in a html table and wants to > > reorder the data by some criteria. Our database wrapper libraries normally > > do not have the ability to resort the cached recordset, so we have to query > > the database with a new ORDER BY criteria. > > > > Here's why ADO and ADO+ is so cool. > > > > ADO/ADO+ has a built-in database engine so you don't have to call the actual > > database server (mysql or oracle etc) to do the sort! Similarly, ADO and > > ADO+ has filtering capabilities so we don't have to requery the server for > > Searches also. > > That's just because ADO+ is not just a database wrapper but also a > middle-ware. This means that it has server processes independent Web > servers or from wherever the client applications are running that can do > all sorts of things like connection pooling or query caching. This can't > be done right just with PHP because unlike other scripting languages > like Java, Perl or Python, PHP does not have multi-threading > capabilities. > > With multi-threading capabilities you could write a middle-ware that > would manage a pool of connections and cache any pertinent queries that > would be done on the middle-ware side. It would not make sense to cache > queries on the client side because that is made just of short-lived web > page scripts. > > I was about to write a connection pooling middleware server for Metabase > but I gave up because of the lack of multi-threading. It would not be > able to handle concurrent queries properly, so it is preferrable to use > persistant connections started by n web servers. > > So, you can hardly blame this apparent limitation of PHP database > wrappers on them, but rather on the PHP limitation of not having proper > multi-threading support. > > Another point is that many times you don't want to cache whole > recordsets. Imagine when you want to query a large database but just > want o view the first n records. It would be very innefficient to cache > whole recordsets because it would spend a lot of time and memory. > Hi Manuel, The caching issues are not a problem if the cache settings are configurable, which i believe they are in ADO+. > > > An ADO+ recordset is XML based with a DTD so ADO+ is self-documenting, and > > we can simulate ADO+ recordsets on non-Microsoft platforms. So just as ADODB > > database wrapper library is a bridge for ASP programmers to migrate to PHP, > > having ADO+ recordset support in Metabase/PEAR/ADODB would be a bridge for > > .NET programmers to move to PHP. > > I'm not sure if I follow you. If storing recordsets in XML was a good > idea, advanced database connection middle-ware products like Tuxedo or > SQL Relay would use XML instead of binary formats. Although it seems a > more portable solution to use XML to exchange data, transferring large > ammounts of data via XML seems to be a very inneficient idea because you > spend an awful ammount of time converting data types from and to text > and formatting them around XML. > > Manuel Lemos > True it is inefficient. But how inefficient? 20 years ago, everyone programmed in 3GL's because of speed issues. Now we are programming in a "real" slow 4GL relative to C. If you are talking about using DOM to parse XML, it will be slow i agree. Custom XML handlers are probably used by M'soft. Regards, John > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > For additional commands, e-mail: pear-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >