The Helsinki declaration: observation 1（Toon Koppelaars, March 12, 2009）

Thursday, March 12, 2009

The Helsinki declaration: observation 1

So why is this blog called the Helsinki Declaration? Obviously it has nothing todo with the real Declaration of Helsinki.Hence the "IT-version" postfix in the title above. In line with thetext of the WMA-version, we could describe the IT-version as follows:

"A set of principles for the IT-community regarding (database) application development"

Ormaybe just: my vision on how database applications should bearchitected and implemented. Previous titles used to bring thismessage, were:

• "A database centric approach to J2EE application development"
• "A database centric approach to web application development"
• "Long live the fat database"
• "Harvesting the advantages of a database centric development approach"
• "Fat databases: a layered approach"

All rather dull titles, not? So ever since Miracle Mayday 2008 with the help of Mogens, the official title of this message has been set to "The Helsinki Declaration". There you have it (as he would have said).

A bit of history.

Beforeexplaining what the declaration is all about, I usually start bydescribing a few observations as I have experienced them in the 20+years of my ride on the Oracle wave. Here is observation 1.


Weare in the year 1987. Oracle version 4. Above a picture of the fulldocumentation set way back then. The arrow is pointing towards thechapter titled "DBA guide". The only chapter on the database: all otherchapters dealt with "tools outside the database" such as:import/export, RPT/RPF, IAF/IAG (predecessor of SQLForms), etc.
Here's another one.


Asyou can see from the abundant use of white-space, there wasn't a wholelot of documentation to read. In fact you could study the fulldocumentation set over weekend. Be ignorant on Friday afternoon. And afull-fledged Oracle expert on Monday morning.
I do not have a picture of the version 5 documentation set. But here's a picture of the (full) version 6 documentation set.


Thearrow now points to the "Oracle RDBMS database administrators guide". Athick book which would take considerably more than a weekend to study.The other thick(er) one you see a bit more to the left, is the"SQLForms3.0 developer's reference".
Next up Oracle7:


Nowmind you. This is *not* the full documentation set anymore. It's justthe stuff for the database. So what was just one book in version 6, nowhas exploded into a dozen of books with Oracle7. Oracle7 of course wasa huge leap forward at that time and started the "golden years" of themid and late nineties for Oracle.
Finally I have a picture of the Oracle8i documentation set (database only again).


Asyou can see it doubled the amount of stuff to read compared to Oracle7.I (and my customers) stopped purchasing hardcopies of the documenationfor Oracle9i and later versions. Pricing of harcopy documentation wentup dramatically as I recall: Oracle wanted us to use the onlinedocumentation. Which we all started doing. But I bet that (had theybeen available) hardcopy versions of the documentation sets of 9i, 10Gand 11G, would continue to double in thickness for every major release.

Inthe past twenty years we observe that the functionality (features) thatis available to us inside the DBMS, has exponentially grown. Thesefeatures enabled us to build database applications. Which is what weall started doing in the booming nineties. At first, with Oracleversions 6 and below which didn't offer much functionality yet insidethe DBMS, other than SQL. I know, there was anonymous PL/SQL, but thatwas hardly used. We had to stuff all functionality into the client andbuilt fat (sqlforms30) client applications. But as more useablefeatures became available, which was definitely the case with theadvent of Oracle7, we started pushing application logic into the DBMS(stored procs etc.). Why? Because we discovered that this created:

1. More manageable applications
2. More performant applications

(I'm not explaining why this was so, now. Maybe in a later post)
So as features became available to us inside the DBMS, we started using them.

Butthen at the dawn of the new millenium, something happened. And thatsomething misteriously made the role of the DBMS inside a databaseapplication project diminish to insignificant. Of course I'm talkingabout Java and J2EE here now, to which I will return in a later post.But as of the new millenium we are pushing all application logic out ofthe DBMS into middle tier servers. The functionality of stuffimplemented outside the DBMS has exploded, and the feature rich DBMS ishardly used for anything but row-storage. Here's a picture from mypresentation showing this.



The blue line shows the exponential growth of features available to us inside the DBMS.
The red line shows how we have adopted those features in the nineties, and ceased using them anymore in the new millenium.
Thegreen line (follows from the red line) shows what part of a databaseapplication is implemented with technologies outside the DBMS.

This is the first observation. Three more to follow.

About Me

Toon Koppelaars

Relational database specialist.(co)Author "Applied Mathematics for Database Professionals".