[development] Data-driven database tables and updates
kieran at civicspacelabs.org
Sat Jun 10 03:19:13 UTC 2006
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
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
However, reporting still rules the world and I think that's where we
should stay focused.
> Dries Buytaert :: http://www.buytaert.net/
More information about the development