Re: Date's First Great Blunder

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.