[development] Referential integrity -- finally?

[Chris Johnson]

On 1/23/07, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> When working with databases you want to know _exactly_ what is
> happening with your fields, types, keys and indices -- and the order
> thereof.  An abstraction layer makes that less transparant.

I believe most of that can be accomadated in a good abstraction layer.
 Few Drupal developers know enough about any given database that they
worry about order of fields and keys.  Just look at all the effort
that Killes went through recently with trying to optimize database
usage for drupal.org.  There were a few of us providing small pieces
of additional information to him, and a lot of reading The Fine Manual
and testing things to see what happened.

I say it is far better to have the abstraction layer so that all of
contrib works on all supported databases, (and we can stop chasing
database-specific install and upgrade bugs), than it is to allow easy
fine-tuning of the database tables by contrib authors.  And we can do
both.

If performance optimization of a table on a particular database gets
to be crucial for a particular contrib author, she can either help
improve the core abstraction code to fix it, or make it possible
through the abstraction layer.  Or she can *bypass* the abstraction
layer and code for the database specifically as we do now, at the cost
of losing compatibility with other databases.  That's a win-win
situation.


> Plus, SQL is already an abstraction layer so we'd be adding an
> abstraction layer on top of an abstraction layer.  It's a little
> implementing a new template language in PHP (cfr. Smarty) -- PHP is
> already a template language.

No, that analogy doesn't hold up.  SQL is no more an abstraction layer
than PHP is or any other high-level language.  SQL and PHP are both
interpreted at run time by interpreters written in C/C++.   (Come on,
let's all code right in machine language!  :-)


> The more I think about it, the more it boils down to this question.
> What do we care more about?  Optimizing Drupal for developers, or
> getting more database experts on board?

Why not both?  Point the database experts at the core and abstraction
SQL, and give the developers an easier way to be cross-database
compatible.  Or do I misunderstand your question?

..chrisxj