Re: Wishing trolls away

From: Bill H <wphaskett_at_THISISMUNGEDatt.net>
Date: Sat, 15 May 2004 15:49:16 GMT
Message-ID: <0_qpc.5824$gr.426309_at_attbi_s52>

Paul:

"Paul" <paul_at_test.com> wrote in message news:vx1pc.3233

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

I can't comment on a single installation and process. I can say an MV (Pick) system is loosly typed and this can cause SQL people consternation. It is difficult to get RDBMS developers to see nothing unusual about a field defined as containing either no data, a date, or only todays date. Business people who have this requirement see nothing unusual in it. So, to say there is an internal Pick problem when exporting data to an RDBMS is likely an opinion based on a limited point of view.

> 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? It seemed to me that Pick
> was very much a "front-end" system, and SQL/relational is very much a
> "back-end" system.

I tend to interpret this as "SQL requires unknown queries" and does well with them. Remember, an MV (Pick) application (as MV consists of both a database and an application) is usually built by business people for

business people.  As such, queries are usually well defined and built into
the application.  The applications developer "optimizes" the query, not the
database system.  So, to think of an MV database in the same terms as an

RDBMS won't answer some of the more germane questions about what is an MV environment.

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

When we think about it, the computing is pretty much the same. If we want a list of employees who were hired after December 2003, we need to either scan the file to select the employees who meet the criteria, then print that list or we need to print the list as we're scaning (unless we want the list sorted), or we need the list already built (as in "optimizing" or "indexing") then select that list then print. An MV way of doing this is pretty much the same: select the list, then generate the output. The list may be generated by scaning the file or by simply selecting a prebuilt list (an index). The complexity can be componetized into data definitions so keep it simple for the user.

> Are there any free/open-source implementations of Pick-style DBMSs?
> 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.

Try the following:

http://www-306.ibm.com/software/data/u2/ for U2

http://www.jbase.com/products/jbase_download.html for jBase

ftp://ftp.rainingdata.com/pub/NT/7.4.0/ for D3NT

or

ftp://ftp.rainingdata.com/pub/Linux/7.4.1/ for D3Linux (RH 9)

Hope this helps.

Bill Received on Sat May 15 2004 - 17:49:16 CEST