I've been working with with TSQL (MS SQLSERVER), lately and 'learned' a lot about it recently. Don't get me wrong, I've been writing sophisticated SQL reports for more than 10 years, and I know a lot about SQL and I'm quite familiar with it. But that's what I was doing writing reports.
As you may know if you are writing a basic report there are three key parts of a SQL statement the SELECT clause, where you output goes, the FROM clause where your table and table relationships go, and the WHERE clause where you choose what data you want to display. (Yes, I know there's ORDER BY, GROUP BY, UNION, etc, but I'm trying to make a point not teach anybody SQL.) What I have discovered is that I've been subtly trapped in this paradigm. If it needs to be output its in the SELECT clause, if it needs to be chosen its in the FROM clause, I may nest SQL statements, but in the end I'm stuck in this single statement framework
I've been able to continue on in with this narrow perspective because, if I may say so myself, I'm pretty good at improvising and finding work arounds, so why should I try something new (its not like I don't know about this stuff), when this works. And besides multiple statements, table variables, where loops, if-then statements, and the like are for something more sophisticated than just reports. And doing it this way does work, but sometimes it's slow, confusing, or just downright frustrating. This week I got past that and wrote a report with multiple statements, table variables, a where loop, and an if-then statements, and it was quite enlightening. I'll never look at SQL the same way, and hopefully I'll remember that there may be more to whatever language I'm using at the time then what I'm working with now. So, perhaps I should climb out of my comfort zone and look around.
P.S. Yes, I'm know I'm a geek because I get excited learning new programming language elements.