Rob Farley

Rob Rob Farley has been consulting in IT since completing a Computer Science degree with first class honours in 1997. Before moving to Adelaide, he worked in consultancies in Melbourne and London. He runs the development department in one of Australia's leading IT firms, as well as doing database application consultancy and training. He heads up the Adelaide SQL Server User Group, and holds several Microsoft certifications.

Rob has been involved with Microsoft technologies for most of his career, but has also done significant work with Oracle and Unix systems. His preferred database is SQL Server and his preferred language is C#. Recently he has been involved with Microsoft Learning in the US, creating and reviewing new content for the next generation of Microsoft exams.

Over the years, Rob's clients have included BP Oil, OneLink Transit, Accenture, Avanade, Australian Electorial Commission, the Chartered Institute of Personnel and Development, the Royal Borough of Kingston, Help The Aged, Unisys, Department of Treasury and Finance (Vic), National Mutual, the Bible Society and others.

Did you mean to come here? My blog is now at

17 March 2006

A few SQL Rules

I just came across Jeff Smith's post (thanks to Darren). I like Jeff's advice. I'm pleased to say that I do all this - despite the odd bit of flak I might take over my use of derived tables. I think derived tables are great.

The very fact that Jeff has made a post like this tells me there are a bunch of people out there who don't do these things, and that makes me really sad. It really frustrates me when people do nasty nasty stuff with their queries, and I often feel like people approach writing a query like they would approach an API. But anyway, I like Jeff's rules.

Here's a thing I quite like these days...

'colname1' = whatever1,
'colname2' = whatever2,

as opposed to:

whatever1 colname1,
whatever2 colname2,

Giving my columns names this way (the first way) means that all my column names are lined up nicely, and even all the definitions are lined up nicely, assuming I hit tab before the equals sign. It means that when I come to glancing at the query, I can see exactly what the result columns are - and this really helps in my derived tables too!