Re: Wishing trolls away

"Paul" <paul_at_test.com> wrote in message news:vx1pc.3233$wI4.332863_at_wards.force9.net...
> Dawn M. Wolthuis wrote:
> > That is what I used to think (and speak on). Then I had and saw teams
of
> > software developers working to make companies productive with SQL-based
> > tools on SQL-DBMS's and the MV query language on MV databases. There
really
> > is no comparison from an "end-user" standpoint. And when trying to make
> > companies that had been using MV query languages now happy or even
satisfied
> > with SQL-based products, it was pretty much impossible. It is my
adventure
> > with reporting tools and query languages that led me to believe that
PICK
> > had something that was both invisible to the industry and superior in
many
> > respects to what folks were doing (SQL).
>
> My anecdotal experience of Pick has been that it was used for an online
> system where it seem to perform fairly well. But the data was exported
> every day to a SQL DBMS for use in queries, reports etc.
>
> Quite often the data that would come over would be corrupted due to some
> internal problems with the Pick system. Whereas in the SQL system the
> only errors would be logical because the DBMS would make sure all the
> constraints were enforced.

You could be right that the issues were with something in the PICK application (I doubt it was in the PICK system), but often there are issues in taking PICK to SQL in that if you don't write special routines to handle it, you can lose information (e.g. ordering) and NULL handling gets botched up.

> Maybe the strength of Pick is for systems that do a lot of simultaneous
> editing and selecting of single records? Whereas the strength of
> relational is for performing complex queries?

That is not the distinction from my experience. I am not aware of any business information systems that would fare better in a SQL-DBMS, although I suspect there could be such.

> It seemed to me that Pick
> was very much a "front-end" system, and SQL/relational is very much a
> "back-end" system.

I use it as a back-end since as a front-end, it is character-based (but can have 3rd party software for writing GUI's instead). It is a good back-end for web-based applications (although there is no obvious packaging of it in this way).

> I've not had direct experience of Pick but my understanding was that
> kind of queries we needed (several layers of subselects, complicated
> EXISTS clauses, aggregation, etc.) would just be too much for Pick, both
> in terms of writing the queries, and running them.
>
> Are there any free/open-source implementations of Pick-style DBMSs?

Maverick (at sourceforge?) is one that has been under development, although I don't know if it is production-ready. It is also more focussed on writing DataBASIC in Java than some of the other aspects of PICK. But you can get a PE edition of UniVerse or UniData from IBM's web site.

> It might be interesting to set up a Pick database and a SQL database on
> the same spec machine, with the same data, and see how they both cope
> with various queries. I've been re-reading the red/blue car exchange
> that was on this newsgroup a while ago; that may be a good one to try.

The Maverick folks were planning to set up a Pet Shop app at some point, and I had done an MV pet store data analysis previously, so I passed that along to them and that could be a possible app.

The key to success with an experiment as you suggest is to ensure that you have a SQL-DBMS designer specify the one and a PICK data designer specify the other based on system requirements that were not written up with a leaning toward one or the other. In other words, you need to start out with each data analyst doing their own interviews of the users to determine data requirements. If you simply attempt to convert the one to the other (even at the spec level), you can dillute the original design and fail to take advantage of features of the other. Make sense? I'd be happy to help out with such an experiment. --dawn Received on Fri May 14 2004 - 14:33:13 CEST