Re: PEAR DB and ADO+

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. > 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