Re: Date's First Great Blunder

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Fri, 23 Apr 2004 13:12:55 -0500
Message-ID: <c6bmbp$abg$1_at_news.netins.net>


"Paul" <paul_at_test.com> wrote in message news:UW9ic.33158$h44.4931728_at_stones.force9.net...
> Dawn M. Wolthuis wrote:
<snip>
> When I said scaling I was actually thinking in terms of more tables,
> more queries, and more complex queries, rather than more rows.

Queries typically are not the issue with PICK -- probably because there is both a query language and a 3GL (DataBASIC) and the query language is quite simple, but can include any virtual fields coded in DataBASIC. From an end-user perspective, queries just reach into a single file cabinet and see everything that can be seen through a single folder at a time. A vast graph of data can be smashed into a flat vocabulary (dictionary) for that "file cabinet". As far as the user is concerned, queries are easy, but the logic to ensure that the vocabulary for the queries includes everything the user might want to query against requires a 3GL programmer for the more complex queries. The biggest issue with queriest is that the language is not SQL-based and therefore, not accessible via ODBC, which is standard for desktop software accessing databases.

There are plenty of ways to stretch the application, but from what I hear, sites don't really end up hitting a limit that requires them to go to an RDBMS. They suggest 30,000+ concurrent users and large files, as well as large numbers of files. Of course, larger systems need more creative tuning, and any application with lots of users against a single huge file would experience more problems than one with lots of users on lots of files.

> But I
> guess the same might apply to that sort of scaling, I don't know enough
> about how Pick works to say that.
>
> I think this example has already been made:
> If you have an invoicing database and the order lines are physically
> stored with the orders (as in Pick), then it is optimised for printing
> invoices. But say you want to know how many orders there are with a
> particular order line?
>
> With relational, your database is already optimized for this; it
> "scales" nicely to the new type of requirement. With Pick I understand
> you'd have some extra work to do by scanning every single order record
> looking for a particular order line.
>
> My experience has been that businesses will ask for the most convoluted
> reports you could imagine, not just the ones that you might think are
> needed at first analysis.

Absolutely -- and that is where PICK often excels, but I will grant that there are pros and cons to queries with an RDBMS and with PICK and there are some queries that are easier to do with SQL, for example (although I can't think of any right now). The kicker is that in EVERY CASE that I have seen (which is quite a few), end-users are much happier with PICK reporting. Someone just let me know about a site that attempted to mvoe from PICK to an RDBMS and then went back to PICK and the users were thrilled to get their reporting language back. So, scaling up as it relates to reporting is not where a limit is hit that would prompt someone to move from PICK to an RDBMS. But I know that flies in the face of the rationale for using the relational model. That's one area where my book-learning and experience are in conflict.

Cheers! --dawn Received on Fri Apr 23 2004 - 20:12:55 CEST

Original text of this message