Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Date's First Great Blunder

Re: Date's First Great Blunder

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Thu, 22 Apr 2004 20:15:03 -0500
Message-ID: <c69qn9$s94$1@news.netins.net>


"Paul" <paul_at_test.com> wrote in message
news:cZYhc.32931$h44.4905402_at_stones.force9.net...
> Dawn M. Wolthuis wrote:
> >>Relational is simpler to the end user, but more complicated to the
> >>database management software.
> >
> > From what I have seen, relational is definitely not simpler to the
end-user
> > of the dbms software (nor of any applications based on that software).
Do
> > you have any evidence to back up this claim? Thanks. --dawn
>
> Not empirical evidence, no. But I don't think this is possible to get.
>
> For a particular instance of a problem, it might be simplest for a user
> to use whatever they are most familiar with.
>
> The thing about relational is that because it has complete
> logical/physical separation, it is very good at covering the general
> case (as opposed to a specific case).
>
> For a particular problem, Pick might work fine, because it's physically
> optimized for certain queries. But say you want a different query that
> you didn't anticipate at design time, the optimization won't be there.
>
> Relational does the optimization at run-time, not at design-time.
>
> I think the only way you're going to get any sort of comparison between
> the two methodologies is if you have two equally experienced teams
> working in parallel from identical specs producing systems and
> maintaining them over several years. And repeat this for several
> different problems in case a problem is biased towards one methodology.
> But this is never going to happen.

I do think there might be some sort of 3-day competition that if repeated frequently enough could give us an idea of the relative merits of the set of software used for each solution (which we might be able to attribute some portion of to the data model, but not the entirety).

> I would have thought given your mathematical background you would
> appreciate the beauty and elegance of the relational approach. I find as
> a (totally non-scientific) rule-of-thumb that gong with the elegant
> solution is always best!

Yes -- bingo and there's my problem. I DO see the elegance in the relational model and, yet, my own professional experience does not bear out the claims that the relational model provides a better environment for the long haul. I recognize that someone else might have experience that verifies for them that the relational model IS the best long-term solution for database software. But I'm trying to square away my own book-learning knowledge with the knowledge from my experience. I'm not convinced that PICK is the end-all and be-all of database solutions, but I KNOW that from what I have seen with my own eyes that I would rather put my money in that type of big bang for the buck (for years on end) solution than pay for an RDBMS shop. So, why is that? Which part of my brain is correct in its assessment?

> It may be that the computing power needed for an efficient RDBMS
> implementation is only recently available. So 20 years ago a Pick
> solution may have been a better option in a practical sense, because
> computers were too slow or lacking in memory for a RDBMS to really work
> properly.

My PICK experience only dates back to '89. My assessment has to do with the productivity of software development teams providing quality software that is very flexible in meeting the ongoing needs of end-users. I'm also not working with VLDBs.

> But now we've maybe reached the critical point of processor
> power and memory, so that true RDBMSs will really come into their own in
> a practical as well as theoretical sense.

My guess is that software professionals will decide there is no real reason for doing object-relational mapping and relational to XML and back for web services. All we need is a database that handles data with a model like that used for XML documents and such back and forth mappings will be easier to maintain. I think we are at the beginning of the end of relational database dominance in new systems (when teams can choose whatever they want) and I don't see a great future for SQL either. SQL is about to go into the COBOL bucket where there are lots of people doing it, but it is legacy stuff. Of course, PICK has been in that bucket for 20 years.

Just thinking outloud for what it's worth. --dawn Received on Thu Apr 22 2004 - 20:15:03 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US