Re: Is a RDBMS needed?

From: Robert Freeman <>
Date: Thu, 9 Jun 2011 11:09:35 -0700 (PDT)
Message-ID: <>

I'm afraid I no longer know who the author of this quote is.... but it seems 
appropriate here:

Anyone can re-invent every system out there from the word go….Is it worth it? Of 
course not.  Why?  Because they'd be INCREASING the total cost of development 
when they ignored previous IT science and development. And ignored what is 
already there, ready to be used, de-bugged, tuned and optimized ten orders of 
magnitude better than what they'd be able to achieve in a typically 

In simple words  Re-inventing wheels COSTS MONEY!  [For Example] To try and 
centralize the datatypevalidation into the app server(s) is inherently 
non-scalable and impossible to maintain without a serious impact on availability 
of the application(s).  Yes, app servers MAY have to run more than one 

Database software was designed, tuned AND debugged to safely and reliably 
support multiple data types, orders of magnitude more efficiently than any j2ee 
project will ever be able to code in any usable time.

These folks should try to use the software that is already there instead of 
re-inventing the wheel for every project they get involved in.

 Robert G. Freeman
Master Principal Consultant, Oracle Corporation, Oracle ACE
Author of various books on RMAN, New Features and this shorter signature line.

opinion of one Oracle employee. I can be wrong, have been wrong in the past and 
will be wrong in the future. If your problem is a critical production problem, 
you should always contact Oracle support for assistance. Statements in this 
email in no way represent Oracle Corporation or any subsidiaries and reflect 
only the opinion of the author of this email.

From: Guillermo Alan Bort <>
Cc: "" <>
Sent: Thu, June 9, 2011 12:01:35 PM
Subject: Re: Is a RDBMS needed?

Well, I think you need to ask yourself why do RDBMS exist in the first place?

I remember a few (not so few, actually) years ago, when I started college and 
first started writing programs (in C no less, and using API32 to have GUI, we 
didn't have any of this .net shenanigans back then). One of the first programs 
that needed persistent data was a calendar. At first I wrote my own file 
management interface and handled data input/output directly into the files. This 
made testing very easy, as I could open the files in notepad and just change 
whatever data I wanted and see how that impacted the application. In time I 
realized that after loading a few months worth of data the application became 
way to slow in basic I/O (as i didn't have any indexing capabilities, it just 
loaded the entire calendar into memory and dumped it back again). I optimized it 
as much as possible but instead of developing my own indexing system, I decided 
to do the only sane thing and move the data to a database. I chose SQLite back 
then, because it's a very light embeded database, and it solved the problem 

I think that the morale of my first-year-programming story is "while something 
may seem like a wonderful idea now, people who spent 20 years developing a 
solution are not complete morons, try to think ahead and find out WHY they did 
what they did"

If you have 100 users and each user is stored in a flat file, you have 100 flat 
files. it's ok, we can handle that. If you have 1mln users... then what? how 
many users before you run out of inodes? (I know, silly example...)

And Eventually you'll want to add more and more functionality and find yourself 
navigating a buttload of code to find out twenty different ways that the data is 
accessed... whereas using a database the *actual* data is accessed only by the 
RDBMS... who then gives the client what it needs...

Now, I'm an APEX developer as well (don't ask, it just happened! I know I just 
lost the right to rant against java developers) and can tell you that almost any 
application that has any non-static content can be turned into a 
database-centric application... so... why move away from a database?

I mean... I honestly can't think of a way to manage application users other than 
from a database...either as db users or using a table and an authentication 
function... (ok, maybe LDAP or NIS can work too)


On Thu, Jun 9, 2011 at 1:46 PM, Blake Wilson <> wrote:

This is a future release that is just being developed to be released in the next 
3-5 years. It is an open source application developed by some of the 
universities that use it. Some large universities throughout the world are 
currently using and contributing to it, including the University of Michigan, 
Indiana, Cornell, Stanford, Yale and Oxford, etc. So, it is not an small time 
application. I am  not so worried about the current release, but the future of 
it. We are not currently using the application, but I am worried about where it 
will be in 5 years and do we want to be there?
>We certainly can save a few bucks on the Oracle licensing, but at what cost? I 
>am glad to here your concerns as well. And yes, I realize that we are all DBA's 
>and may be somewhat prejudiced, but I think there is a some potential trouble 
>here in a few years.
>Thank you for you responses and ideas.

Received on Thu Jun 09 2011 - 13:09:35 CDT

Original text of this message