Archives of the TeradataForum

Message Posted: Fri, 11 Jul 2008 @ 21:54:18 GMT

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

Hi Graham,

I think one of the main factors is to look at how often in your process you are going to access that view, if it's several times it would probably be better to create a Temp table to bypass the overhead of reprocessing the code in the view each time you needed to access the data.

Teradata say that complex views as you describe have no overhead compare to the underlying SQL (the resolver rewrites the whole SQL of the query prior to it reaching the parser), fair enough, but for support and maintenance purposes you need to look at how the view is accessed - is it going to be joined to many other complex views for example (I assume so from your description) so should a failure or a spool error etc. Occur you can pinpoint exactly were it happened and narrow your field of investigation at the off.

I have often seen the inclusion of this sort of complex view as a solution to the limitations of an ETL tools SQL generation, but in your case you have the structure in place to use the code to build either temp tables or combinations of temp and derived tables, both of which would make diagnosis and tracking future problems easier.

Hope this helps

Jeff

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