Subject | RE: [IB-Architect] Data clustering |
---|---|
Author | Ann W. Harrison |
Post date | 2001-06-28T16:58:48Z |
At 12:06 PM 6/28/2001 -0400, Leyne, Sean wrote:
"clustering" fields. New data would not be clustered until the next
backup/restore cycle. Worst case would be no worse than the current
case. If the data were reasonably stable, it might help in cases like
this...
You have 10,000 customers. On the average each customer has placed 15
orders with you over 2 years. 90% of the time, you want to see orders
associated with a customer rather than orders associated with a date.
However, the orders were entered by date. The probability is that the
15 orders from any one customer will be on 15 different pages. This
pseudo-clustering would put each customer's orders together on a page
or two.
Jim says that giving gbak an input script is the way to go. Contrary
beast.
Regards,
Ann
www.ibphoenix.com
We have answers.
>Could you please explain what advantage there would be to having theUpdates wouldn't be a problem - unless, of course, you altered the
>table initially stored in a sorted order. Once any updates took place
>the 'table order' would be lost.
"clustering" fields. New data would not be clustered until the next
backup/restore cycle. Worst case would be no worse than the current
case. If the data were reasonably stable, it might help in cases like
this...
You have 10,000 customers. On the average each customer has placed 15
orders with you over 2 years. 90% of the time, you want to see orders
associated with a customer rather than orders associated with a date.
However, the orders were entered by date. The probability is that the
15 orders from any one customer will be on 15 different pages. This
pseudo-clustering would put each customer's orders together on a page
or two.
Jim says that giving gbak an input script is the way to go. Contrary
beast.
Regards,
Ann
www.ibphoenix.com
We have answers.