Archives of the TeradataForum

Message Posted: Tue, 05 Jul 2011 @ 22:24:32 GMT

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

My advice is not to use SET tables at all.

There is no other major RDBMS vendor employing this concept, so relying on Teradata SET for duplicate checks would be against code portability, and portability is very important these days.

If you can't rely on ETL for duplicate checks, you need another ETL.

On the performance side, SET duplicate checks cost roughly 30% of a typical "serious" ETL job's time. Big shame to lose time on this when you already know from the previous phases of ETL that there won't be any duplicates.

Forget SET. It's all water under the bridge.

Victor

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