Re: Date's First Great Blunder

From: Paul <paul_at_test.com>
Date: Fri, 23 Apr 2004 10:12:20 +0100
Message-ID: <w95ic.35937$Y%6.4701359@wards.force9.net>

Dawn M. Wolthuis wrote:
> 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 think the benefits of relational are more long-term though. It may or may not take longer to set up, but it's over the whole product lifecycle that you'll see the advantages of the querying flexibility and the centralised constraint enforcement.

>> 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?

Supoose you're an engineer that has to solve some complex differential equations. You could go down the theoretical route and solve them analytically. Or you could just use numerical methods and get an approximate solution that is fine for your needs.

Not a perfect analogy but it may be that Pick is "good enough" for small projects that don't need the flexibilty and power of relational. But I still think (though can't prove) relational scales better and will work better in a larger "enterprise" setting.

>> 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.

I think comparing Pick and RDBMS might be comparing apples with oranges as well. As I understand it Pick is both the database and the front-end, whereas a RDBMS deals only with the back-end. Maybe an practical advantage of Pick is this integration of front- and back-end? Is it possible to use Pick just as the back-end and use, say, Visual Basic as the front end? Is this ever done in practice?

> 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.

Well I kind of agree, but I think it will be XML that will fall from vogue rather than relational :)

Paul. Received on Fri Apr 23 2004 - 04:12:20 CDT