Re: Date's First Great Blunder

From: Dawn M. Wolthuis <>
Date: Fri, 23 Apr 2004 08:33:47 -0500
Message-ID: <c6b60a$fu1$>

"Paul" <> wrote in message news:w95ic.35937$
> 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.

That's what the PICK folks say too, by the way.

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

While it seems to me that the PICK model is much more flexible (but I don't have evidence to prove that), I will grant that all of the systems I have seen that use the model are mid-range in size. I suspect that when you need to scale beyond the millions to the billions of stored "records" in one "file" you might be out of the PICK league. I'll have to ask some pickies about scaling up. I'm more inclined to think that recent approaches to scale, such as clustering, might apply to the big guys where PICK might be left in the dust on newer scaling techniques.

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

If we start with a problem statement (from the business world) and then see where we can apply either, there is significant overlap. In fact, other than the VLDB arena (and I have recently heard that PICK is a part of Terradata toolset behind the scenes somewhere), there are likely vertical markets that are not very strong for PICK -- I don't know what these would be, but I can't think of much use for scientific or multimedia databases. While PICK could be used for these, it is in its niche in business data processing -- manufacturing, financial, banking, health care, education admin, and many, many more.

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

Yes, I use PICK as the backend with Java, for example, while others use VB. However, when doing that you typically still use the PICK languages for building virtual fields and other data management work ('cause it is easier that way).

> > 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 :)

I'm guessing that Vegas doesn't give odds on that one. Let's check back in on this in 15 years. smiles. --dawn Received on Fri Apr 23 2004 - 15:33:47 CEST

Original text of this message