Archives of the TeradataForum

Message Posted: Thu, 02 Feb 2006 @ 18:02:39 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

<-- Anonymously Posted: Thursday, February 02, 2006 12:09 -->

Dave,

Our solution implements the PI on Order and the Order Line with the natural identifier of ORDER_NBR.

ORDER uses a UPI. ORDER_LINE uses a NUPI. No PPI due to volume (less than 100M Order Lines) and the lack of a suitable column for PPI that could be guaranteed to exist in the WHERE clause most of the times.

We have a separate dimensional model with 2 fact tables to capture Order Related Metrics such as Last Order, Last Qty, Next Order, Next Qty, Next Arrival Date, Last Arrival date, Vendor Performance, etc.

Inserts into ORDER, ORDER LINE (and the related packing lists) are a non issue (one is a UPI, the other one a NUPI with low dup threshold values). ETL quarantines ORDER_LINES with duplicate Line Numbers.

The BTEQs that REFRESH the 2 dimensional models take 6~8 minutes to run after the ETL completes. The reports on those metrics are very, very fast. Some of them delivered ONLINE via a Visual Basic application to users (when will the next shipment arrive?).

No Secondary Indexes are defined on either table and no new metrics have been discovered since go-live. Requests for Data mining in this subject area have been minimal.

Anonym

	<Prev	Next>		<<First	<Prev	Next>	Last>>