Late to the ball - and only picking up on one issue... On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> 2. Always separate out any usage stages that can be performed apart > from the database itself. This allows an application to do those > stages more efficiently, consuming fewer resources of both itself and > the database. > > For example, a pre-forked Apache process can declare all of the > database and statement handles that it plans to use, and do as much > of the prepare()-type work that can be done internally as possible, > prior to forking; all of that work can be done just once, saving CPU, > and only one instance of it consumes RAM. All actual invocations of > a database, the open()/connect() and execute() happen after forking, > and at that point all of the database-involving work is consolidated. > > Or even when you have a single process, most of the work you have to > do, including any SQL generation et al, can be more easily be > pre-performed and the results cached for multiple later uses. Some > DBI wrappers may do a lot of work with SQL generation et al and be > slow, but if this work is mainly preparatory, they can still be used > in a high-speed environment as that work tends to only need doing > once. Most of the prep work of a DBI wrapper can be done effectively > prior to ever opening the database connection. > I dunno which DBMS support prepare without a database connection, but I would expect all the mainstream databases to require a database connection. IBM DB2 does; IBM Informix Dynamic Server (IDS) does; someone else commented on this and said Oracle does; I would expect both Sybase and MS SQL Server to need the DB connection too. Probably PostgreSQL; not sure about MySQL. The only systems that might not need the DB connection are those that aren't using a separate SQL-based database server. I'm also far from convinced that there's any significant benefit in separating the 'create a database handle' from the 'connect to database server' part. The overhead of creating the handle - as distinct from make the connection to the DBMS - is negligible. There's nothing of any significance that can be done with the unconnected handle either - at least, for the mainstream SQL DBMS. So, the pre-fork creation of an unconnected handle provides negligible savings. Similar comments apply to the statement handles - in IDS, at any rate, there's nothing useful that can be done for statements until you've got a database handle. Or, at the least, you'd be moving away from the ODBC paradigm, and the ESQL/C paradgm too. As a general comment on DBI v2; we need to beware of the second-system effect (Brooks "Mythical Man Month"). In particular, the DBI must not mandate impossible levels of support from the drivers. It will benefit you nothing if the DBI is immaculate and wonderful and incredibly all-singing and all-dancing, but no-one can write a driver for it because the requirements cannot be met by the actual DBMS that Perl + DBI needs to work with. -- Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h> Guardian of DBD::Informix - v2005.01 - http://dbi.perl.org "I don't suffer from insanity - I enjoy every minute of it."
