On 1/23/07, Dries Buytaert <dries.buytaert@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