On 23-Jan-07, at 12:35 PM, Dries Buytaert 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.
But when you're working with Drupal, you're not working with database fields, tables, etc.. you're working with Nodes, Terms, Vocabularies, Comments, Users and the like. The fact that these just happen to be stored in a SQL database is not terribly important to ones line of thinking when developing most modules. (If you're really concerned about the specifics of your data at the database level, you would mandate that the application use stored procedures for everything. ;) Requiring that someone be well versed in SQL to do a lot of development in Drupal is already a barrier to entry. And most people are not expert DBA's. Just look at the schemas for some of core and contrib :)
At the same time, an abstraction layer makes it easier to port and update modules.
PHP has a crap database API. So (to Adrian's point) the only way to avoid killing contrib developers and core maintainers with schema management across X number of databases X-1 of which will most likely not be their primary SQL dialect is to provide a thin layer for the parts of SQL that are completely not standardized across implementations. So that for sure includes table creation, and altering, and also potentially date/time functions if we were to ever consider moving away from timestamps to leverage good database support for date and time data types. Module developers are already NOT writing pure SQL to create and alter their tables.. so we've already thrown up a layer in there that is ideal for neither developers nor db admins. Why not help developers out so that they need only write one db_table_create() or db_table_alter() statement instead of 2 or more? -Rowan