[development] Data-driven database tables and updates

[Kieran Lal]

On Jun 9, 2006, at 3:31 PM, Dries Buytaert wrote:

>
> On 09 Jun 2006, at 19:44, Adrian Rossouw wrote:
>>> Adrian Roussow is working on something like this already.
>
>> I wish I was. But sadly Dries has (in no uncertain terms) said he  
>> didn't like the idea.
>
> If the majority of the people think this is a good idea, I'd be  
> happy to go with this direction.
>
> As mentioned, I understand the advantages of said system, but I  
> still prefer the transparency and simplicity of "raw" SQL statements.
>
> SQL is an abstraction layer, and one that is documented in hundreds  
> of books and articles.   It is my opinion that creating a Drupal- 
> specific abstraction layer on top of an existing, standards  
> compliant abstraction layer used by hundreds of thousands of people  
> creates an additional barrier for developers that are new to  
> Drupal, but that are familiar to SQL.
>
> I, for one, wouldn't want to learn an application specific SQL-like  
> description language.  As a developer, it would sorta turn me off,  
> and make me shout 'bloat!'.

The data management battle has boiled down down to three basic  
implementations over the last 40 years: relational (System R, Oracle,  
MySQL), hierarchical (LDAP and IMS), and network,now abstracted as  
object or XML databases which is closest to the proposed new system  
at first glance.  Each has had its moment.

Relational wins every time, not because of a standard, performance,  
or because developers like to use it.  It wins because it has  
superior reporting capabilities that allow for the boss to ask  
questions and get answers fast.   Bosses who get the right  
information faster tend to stay in business longer.  If we choose to  
stay with a relational and SQL based query model then we need to  
ensure that our priority is on reporting.   What this means for core  
is that we must compete against the alternate solutions in several  
ways to have a better overall package.

1) A better interface for statistics to provide advanced reporting  
analysis.
2) Integration of Views into core to allow administrator capable  
reporting to the UI. E.g. Calendar views.
3) A focus on supporting built in analysis like the SOC project  
Social Network Analysis Tool, and other data analysis techniques like  
data mining and data ware housing.

If we choose to take the ROR Network/Object/XML DB path then we will  
have a lot of very happy developers who will buy lots of books, sell  
out conferences for a while and then realize we can't give the  
executive's the answers fast enough before they layoff the techies.

Alternately, we can choose the Hierarchical DB Model and build one  
really big hierarchical database like Google's Big Table project to  
store the worlds content.  This will ensure Google stays speedy for  
all of us. It has it's place in a world where search competes for  
public attention.

However, reporting still rules the world and I think that's where we  
should stay focused.

Kieran

>
> --
> Dries Buytaert  ::  http://www.buytaert.net/
>
>