[development] Referential integrity -- finally?

[Rowan Kerr]

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