Many experienced SQL and procedure developers use SQL functions to perform common tasks and simplify their code narratives. The function concept is a good programming technique, but adopting it literally in a Set SQL statement may force the statement to execute as a serial process; that is, it can make parallel processing impossible.  This is one reason Teradata SQL does not allow functions to access tables.

Ordered analytical functions enable parallel processing by freeing processes from flat logic. They also produce simpler Set SQL statements, which as a general rule can be expected to perform better than more complex Set SQL statements.

Set SQL is a way of operating on data that is radically different from historical concepts of computer programming that can be diagrammed with flow charts.  Grab a cup of coffee and review some history that will explain why the industry is mired in cursor logic and loops that cannot exploit the power of today's software and hardware.

When Flat SQL looping logic involves complex processing of data elements from multiple tables, the loops can almost always be transformed into Set SQL with derived tables. By eliminating looping logic, the performance benefits of parallel processing can be exploited.

The most difficult task when converting Flat SQL (cursor-based procedural code) to Set SQL involves translating complex logic and accounting for multiple data sources.  The Derived Table feature of Set SQL simplifies this process.

Perhaps the easiest way to transition from a flat logic mindset to a set logic mindset is to convert some Flat SQL to Set SQL, then stare at both of them until the logical equivalence of the two approaches becomes clear.

Maximizing the full potential of Teradata's Massive Parallel Processing requires Set Processing.