[development] Referential integrity -- finally?

[Gerhard Killesreiter]

Dries Buytaert wrote:
> 
> On 23 Jan 2007, at 13:04, Gerhard Killesreiter wrote:
>>
>> Problem is that Dries doesn't like this _at_ _all_. :p
>>
>> His argument is IIRC that we should stick to as plain SQL as possible 
>> to not further increase the barrier of entry for people already 
>> knowing SQL.
> 
> When working with databases you want to know _exactly_ what is happening 
> with your fields, types, keys and indices -- and the order thereof. 

Currently, we don't care at all about the order of fields in a table. 
Furthermore, if we add a field later, we just append it to the table. 
This causes the structure of an old Drupal install to be different from 
new installs.

And, quite frankly, most Drupal developers including myself wouldn't 
have a clue for what order of fields should be preferred.

> An 
> abstraction layer makes that less transparant.

True, but for example the functions used for pgsql are quite transparent.

> 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.

Well, Drupal _is_ already an abstration layer on top of PHP. We have 
hooks, special conventions (check_plain & firends), etc.

> At the same time, an abstraction layer makes it easier to port and 
> update modules.
> 
> Conclusion: there is no win-win situation -- each direction has 
> advantages and disadvantages.

Yeah, but we need a decision on what to do.

This is not only valid for db_add_columns & friends, but also for other 
things like db_insert &tc that have been proposed.

>> While his argument has merit, I think it is put ad absurdum by the 
>> fact, that Drupal doesn't have any plain sql files anymore.
> 
> Yes, with the install system, the facts has changed.  "Ad absurdum" is 
> too strong a word (but it sure sounds cool. ;)

I knew you'd like it. :p

>  I don't mind us opening this discussion again.

I think we should have added a database.*sql file to Drupal 5 before 
releasing it. If I download an unkown product that depends on a 
database, I tend to first look at the sql definitions. It tells me a lot 
about how well engineered the project is. It would not hurt if the db 
schema would be documented.

> 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?

Well, he have been using the current way of doing SQL for some time now 
and the number of SQL savvy Drupal people is still low. Maybe we try 
something else now?

Also, I have found a few people in #drupal that help me with with SQL 
related questions. Nobody has yet complained about our API. Of course i 
usually feed them the processed queries from the database logs.

Cheers,
	Gerhard