Why does writing really neat Teradata SQL matter? Well, read on to find out more.
We all know massively parallel processing (MPP) databases like nothing more than plain old set-based batch SQL scripts to chew on, right? Where would we be without SQL clients like Teradata'sBTEQ, Netezza nzsql or Greenplum psql? Lost, probably.
Parallel databases are quite picky - they like to run things in parallel. Those complicated procedural programming languages don't lend themselves to parallel execution by our favourite MPP databases. The upshot? No pesky procedural programming for us Teradata, Netezza or Greenplum jockeys, no sir! Java? Nope. C? Nope. Cobol? Well, maybe.
The good thing about batch Teradata SQL scripts is that they're easy to write, is it not? Developers in the IT department and business users alike can all develop Teradata SQL scripts that can be run once, many times, or even implemented into production to run on the schedule. Happy days.
Let's face it there are only 4 basic commands to worry about:
select - get me stuff from the database
insert - add stuff to the database
update - change stuff in the database
delete - get rid of stuff from the database
There's even an acronym to describe these commands collectively: CRUD
So, MPP databases *really* like SQL *and* its easy to write, so what's the problem?
Well, the problem is exactly that - Teradata SQL is easy to write. It's also very easy to write badly.
And here's the secret : poorly formatted Teradata SQL runs slower than well formatted Teradata SQL.
In a nutshell, neat Teradata SQL is fast, really neat Teradata SQL (RNSQL) is even faster.
When we are dealing with terabytes of data in a single table and queries that span tens or even hundreds of processing nodes, optimal code is really important.
So, what's the take-away message? Easy - Teradata SQL formatting matters a lot. Always aim to feed your database RNSQL. It deserves it.