Archives of the TeradataForum
Message Posted: Mon, 11 Sep 2001 @ 00:42:44 GMT
Jim, I will take a shot at this question.
I believe Igor is familiar with RDBMS's that either materialize a copy of the table with an indexed access path or with a materialized view via a concept similar to our join index / aggregate index functionality.
Igor, I think that you should get a very good overview of Teradata from someone (possibly on this list) and how to use our system functions to provide the functionality that you are looking to provide.
Just know that in Teradata, there are often many ways to accomplish the same task.
I suggest trying the most simple approach first. Most of the time the simple approach provide many times to 100's times better performance than you are used to.
If you still need better performance then try adding additional structures like secondary indexes, join / aggregate indexing, summary tables, derived tables, etc... to improve performance.
The other alternative is to specify your requirements in a very detailed manner including performance expectations so someone on the list can help guide you in the right direction. However, this will probably be hard to do in a short period of time unless the scope is very narrow. I suggest hiring someone to help you build up your Teradata expertise and build your confidence in it's strengths. Education will also help in this area. The Teradata Design class (the old Physical Database Design class) is highly recommended.
My experience has been that less than 1 problem in 10,000+ (a large number) can't be accomplished in some manner and the problems that I deal with are fairly complex. Recently, we've even done 2 versions of a householding algorithm with Teradata. We often see 30 + table joins with 100's of spool tables, derived tables, and 10's of sub-queries etc... Normally, you can try just about any level of complexity that you can code.
Performance is a function of both size and complexity, but can often be largely offset by physical design choices.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|