I'll be the first to admit that I'm a bit of a T-SQL zealot when it comes to doing things with data. A part of the reason is that I've been using it very effectively for all manner of things, including a lot of things that people say "Just because you can do something in T-SQL, doesn't mean you should".
To that, I say rubbish and will many times retort with "Just because you can do something in T-SQL, doesn't mean you shouldn't". Sometimes, I'll get a bit more focused and retort with "Just because you can do something in (.net, C#, Python, PowerShell, whatever), doesn't mean you should".
No... that's not me actually being an old stuck-in-the-mud fuddy-duddy. That's me being practical.
Stop and think about it... for the longest time, it was one of the very few languages where you could access huge files of data and never had to write a loop. A Select IS A LOOP!!! And, a very well written one at that complete with error checking and the whole 9 yards. When working with "conventional data" and even some "unconventional data", it's a beautiful thing because I don't have to write loops and I don't have to teach myself a whole new language just because someone decides to poop out a new one. I have great respect and pity for Front-End Developers that have to "keep up" with today's shiny new object even if it doesn't work as well as the one from last decade. I'm also not really a Luddite. If a change is good and it's not something that I can already do or it's something that's going to make life truly easier, more accurate, quicker, and easy to adopt, then I'll try those shoes on and wear them so long as they continue to do the job and continue to be comfortable.
Now... I told you that story to tell you this one.
IMHO, I've been quite successful. I believe that the thing that has made me successful is to embrace just one thing... how data is stored and accessed. I believe that having archaic knowledge of hand-assembled machine language from days long gone have been a real key to that success. I know it sounds crazy but it has allowed me to more readily grasp the concept that people call "Set Based Programming" because I know behind the scenes some of the possible ways it is implemented. It's like knowing that a SELECT is, as its basis, is really an elaborate loop.
Once you understand that, you can do just about anything because the truth is, computers haven't changed since they were invented. All you have to do is study the new stuff, learn the syntax (which is then biggest challenge, especially with curly-braced languages), and learn "replacement functionality". Most people already know what they need to do with or to the data. They just need to learn things like the DATEDIFF function in one language can be totally different than the DATEDIFF function in another.
If you want to be "future proof", you don't need to learn or even know of dozens of languages, etc, etc, ad infinitum. You just need to know that computers have 4 parts... Input, CPU, Output, and Storage. If you have a deep understanding of that, then you can do anything that you want to with a little study for whatever task is put before you.
You can also do things like say "That's real nice but let me show you how simple that is to do in T-SQL". 😀
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)