[development] Re: enterprise needs
chris at tinpixel.com
Mon Feb 27 17:15:01 UTC 2006
Adrian Rossouw wrote:
> On 27 Feb 2006, at 6:11 PM, Darrel O'Pry wrote:
>> with 1) you may get slightly better performance since you aren't
>> constantly parsing strings, but you start making some major changes to
>> drupal's db_abstraction layer.
> How long before it makes sense to just use a third party db abstraction
> library ?
> I'm not hot on the idea of re-inventing the wheel yet again.
> Adrian Rossouw
I think that may be a tougher question than it appears on the surface. I
would say we should use a third party db abstraction just as soon as one with
a good fit and performance is written. :-)
Right now, most db abstractions are written to be ultimately generic, so that
as many people as possible might be able to use them. The number which were
written intentionally to be lightweight and for web applications is very
small. In the former category are things like ADOdb and PEAR DB. In the
latter category is PHPLIB's.
ADOdb and PEAR DB might have as many lines of code by themselves as all of
Drupal core -- they're that big. None of them abstract the database
completely, really. You still have to write database-specific SQL statements.
A real abstraction would allow you to encapsulate the database objects as
objects, and the code reading and writing the attributes of those objects
would never need to use SQL. I'm not sure if we want to go that far, or not.
(Incidentally, I'm writing such a "real" object abstraction for MySQL and
PostgreSQL for my employer right now.)
Are there any other db abstraction libraries out there we should look at? I
certainly would be interested in taking a look at them myself.
More information about the development