Re: Date's First Great Blunder

From: Paul <paul_at_test.com>
Date: Fri, 23 Apr 2004 15:44:11 +0100
Message-ID: <UW9ic.33158$h44.4931728_at_stones.force9.net>


Dawn M. Wolthuis wrote:
> 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.

When I said scaling I was actually thinking in terms of more tables, more queries, and more complex queries, rather than more rows. 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.

Paul. Received on Fri Apr 23 2004 - 16:44:11 CEST

Original text of this message