[development] Extend database abstraction layer, to includetablecreation.

[Khalid B]

On 5/14/06, Larry Garfield <larry at garfieldtech.com> wrote:
> On Saturday 13 May 2006 12:06, Khalid B wrote:
>
> > http://jeremy.zawodny.com/blog/archives/002194.html
> >
> > His main points are:
> >
> > 1. With abstraction layers, performance cannot be gained.
>
> Depends on your performance measurement.  Abstraction layers are not about
> improving system performance; they're about improving developer performance.
>
> We could make Drupal a hundred times faster if we recoded it in hand-tweaked
> x86 assembler.  It would take us a few years to get something even get
> something marginally useful, but it would be faster because we'd have
> eliminated a dozen abstraction layers!  (PHP, C, SQL, etc.)  I'd rather burn
> a few cycles than a few days or weeks of my time.  Hardware costs less than I
> do.
>
> > 2. Changing databases is never easy for a large site.
>
> Depends on your codebase, and if you planned ahead.

Let me play devil's advocate here ...

The problem with an abstraction layer for the database that we are proposing
is that :

1. It is not complete, since engine specific SQL statements can be embedded,
and hence portability will be lost in this case. There is a false
sense of portability
that is there.

2. It is a lowest common denominator thing, and hence is dumbed down.

3. When you want to do things in the backend because you do not
want to retreive the data in the middle tier (PHP) and incurr a performance
penalty, you often have engine specific syntax (think of UNIX_TIME functions
for example, date intervals, ...etc.)

End Devil's Advocate mode.

I am not against the database creation stuff that Adrian proposed.

What I see is that in the future we may move to total abstraction.

If we realize that we can no longer optimize for a specific engine
without losing
portability, OR that we allow it at the risk of losing portability,
then we should
be fine.

The problem is where we are under the illusion that we have something
(portability
and performance) but we are not.