SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


How Far are You Willing To Go To Get Something?


How Far are You Willing To Go To Get Something?

Author
Message
bkubicek
bkubicek
SSCrazy Eights
SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)

Group: General Forum Members
Points: 8220 Visits: 1012
That is an interesting thought. So exactly what sort of old stuff are you talking about? In most cases on the dev side I don't encourage people to learn C++, I would point them more toward .net C#. It is sort of interesting on the db side because people can be so isolated in what they do. For instance a DB admin, knows how to setup / install sql server. Get backups going etc. Still, their t-sql skill may be terrible. Anyway, let me know what sort of old stuff you think people should be learning, try to be more specific.

Thanks for your comment.

Ben
xsevensinzx
xsevensinzx
SSCoach
SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)

Group: General Forum Members
Points: 18167 Visits: 5140
bkubicek - Wednesday, November 1, 2017 6:24 AM
That is an interesting thought. So exactly what sort of old stuff are you talking about? In most cases on the dev side I don't encourage people to learn C++, I would point them more toward .net C#. It is sort of interesting on the db side because people can be so isolated in what they do. For instance a DB admin, knows how to setup / install sql server. Get backups going etc. Still, their t-sql skill may be terrible. Anyway, let me know what sort of old stuff you think people should be learning, try to be more specific.

Thanks for your comment.

Ben

I think he is mostly referring to the fact people are quick to jump on something new rather than take the time to fully lean what they have.

Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)

Group: General Forum Members
Points: 792020 Visits: 45937
bkubicek - Wednesday, November 1, 2017 6:24 AM
That is an interesting thought. So exactly what sort of old stuff are you talking about? In most cases on the dev side I don't encourage people to learn C++, I would point them more toward .net C#. It is sort of interesting on the db side because people can be so isolated in what they do. For instance a DB admin, knows how to setup / install sql server. Get backups going etc. Still, their t-sql skill may be terrible. Anyway, let me know what sort of old stuff you think people should be learning, try to be more specific.

Thanks for your comment.

Ben


It's mostly the T-SQL skills I'm talking about but there are other things, as well.

For some examples on the T-SQL side... and, no, I couldn't make this stuff up because it's just too fantastic... I had a "developer" bring me some code to review that would create a CLR. I told him that I wouldn't allow that particular CLR to go in and before I could explain why and how easy it was to do in T-SQL, he said something to the effect of "We'll just see about that" and stormed out of the room. To make a much longer story shorter, he convinced the managers to call me out on the carpet in a grand meeting designed to disgrace me and compel me to allow the code. I explained how simple and, basically, how stupid the code was and now the "developer" was on the spot. What was the CLR for? It was an SQLCLR function to calculate modulus. You know, the thing that the "%" operator is for.

Anther wrote an SQLCLR to do an "UPSERT" in SQL Server 2000 (most use Merge nowadays) because he couldn't figure out how to do it in T-SQL. Very nearly the same result there.

Then there are things like code just flat out taking too long to run. One company asked me to stand up an entire server just so they could do this one year end report because "we've always had to do this because the code cripples the production server". They were right... in testing, it would run TempDB out of space every time. I made one Temp Table to hold a small amount of interim data and their more than 30 table join single query suddenly went from taking more than 30 minutes and crushing the server down to 3 seconds and didn't even show up on PerfMon for CPU usage.

Then there are really old things like using very high performance CROSS TABs instead of using PIVOTs. CROSS TABS used to be covered in Books Online but no more. Now they tell you how to use PIVOT.

Then there's all those DBAs that I've interviewed that don't know how to do a native backup and restore because they bought tools to do that and are dead meat when a company tells them they're not buying those tools.

Heh... then, there was the initial PowerShell craze. If you hadn't converted your enterprise-wide backups to being centrally controlled from a PowerShell script, well you just weren't a cool kid. But no one considered what happens to all the log files and related drive space on all your servers if that one central controlling system went south for the winter. Since I did it the old way where each server is autonomous in the area of backups, I never had to worry about that.

There's also the proverbial "Tower of Babel" in ETL systems. SSIS. Web Methods. Business Objects. Whatever. How many times have we heard "and then you write a script task" in conjunction with all those things? For everything that I've had to do for the last 20 years, the old stuff such as BCP, BULK INSERT, and a smattering of DOS along with a bit of T-SQL has worked just fine and continues to do so with great performance on some rather large files sourced from the 4 corners of the U.S.A. from multiple source types for anything from (ugh!) reel-to-real tapes and modems to SFTP sites.and even some good ol' fashioned web site screen scrapping.

And then there's system monitoring. The company I currently work for spent a small fortune on software that monitors systems and hard disks and performance and ... and... and. To date, none of that software has actually been able to identify performance problems. None of it has actually given enough warning about hard disks that have crossed the 10% free space line nor been able to predict when the hard disk will run out of space based on the bazillion bytes of history that's been stored over the years. But, my old stuff does. For example, I wrote a system using T-SQL and makes some calls to old WMI using old xp_CmdShell. Every morning, I get a single email that says out of the 285 systems that the code monitors, here's the small handful of disks that we need to watch or expand including disks that have an "IsDirty" bit set that will need a DiskScan on the next reboot. It even checks all the servers for portable storage devices like CDs, memory sticks, and other USB devices to help the Network Operations folks find such devices they may have misplaced and can't find. It's all old stuff and it all still works.

Those are just some of the examples of the old stuff or old ways of doing things and the reason why it still works for me is that I took the time to learn the tools that are available on every SQL Server including T-SQL, DOS, and WMI instead of being distracted by purple squirrels and the latest cool-kid stuff that sometimes goes away in just a month or two.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
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

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
bkubicek
bkubicek
SSCrazy Eights
SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)

Group: General Forum Members
Points: 8220 Visits: 1012
Hi Jeff,
I really appreciate you taking the time to reply with so much detail. I agree with a lot of what you posted. I am not totally sure I would steer people toward dos and batch files. I have also used those a lot, but I am trying to get more familiar with Powershell instead. I do agree that sometimes people do just go after the latest shiny thing, but I would guess those people aren't really learning things all that well. I would hope when they learn something new they are able to apply it to real world problems and do something practical with that knowledge. Anyway, I do appreciate your post and perhaps an article will be born out of it.

Thanks,
Ben
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)

Group: General Forum Members
Points: 792020 Visits: 45937
bkubicek - Thursday, November 2, 2017 6:33 AM
Hi Jeff,
I really appreciate you taking the time to reply with so much detail. I agree with a lot of what you posted. I am not totally sure I would steer people toward dos and batch files. I have also used those a lot, but I am trying to get more familiar with Powershell instead. I do agree that sometimes people do just go after the latest shiny thing, but I would guess those people aren't really learning things all that well. I would hope when they learn something new they are able to apply it to real world problems and do something practical with that knowledge. Anyway, I do appreciate your post and perhaps an article will be born out of it.

Thanks,
Ben

Just to continue the interesting conversation a bit (and thank you for engaging), I've underlined a bit in your quote above.

On the not steering people towards DOS and Batch Files thing, I do understand that although I'd likely make the suggestion when it's actually appropriate (oddly enough, though, I do find it to be appropriate more often than not but that's me). The key here is that you DO know that bit of "old stuff" and have a basis to measure something new against. A lot of people aren't even aware that things like DOS and WMI exist never mind the power that's built into them. Heh... I tried to explain to someone how to step through some files to do something fairly easy and I told them about "the FORFILES command in DOS". Their question was "Ok... that's cool. What's DOS"? <headdesk>

On the learning PowerShell thing, I have mixed feelings about it. One of the reasons why I like SQL Server so much is that I don't have to write loops. They're auto-magically built into things like the SELECT statement and I refer to those loops behind the scenes as "Pseudo-Cursor". With PowerShell, I've found that it's mostly procedural and does require a fair bit of looping. Even certain DOS commands, like FORFILES, have Pseudo-Cursors in them so I don't have to write explicit loops. Yeah, I know... I'm lazy but in a good kind of way. Wink

I also find that a lot of people that are apparently more comfortable with procedural languages using PowerShell to do things in SQL Server that can be a whole lot easier to do within SQL Server if you just know how. That's one of the primary points that I've been trying to make about using other things instead of using the thing that's old and has always been there.

On that note, there's been some incredible work done in PowerShell and you wouldn't expect otherwise from such a powerful tool. For example, there's a code set for PowerShell called "DBATools" and, from what I've seen, it does have some awesome tools built in. The trouble is, it's like an application... it's not currently (if I understand correctly) something that's built in and maintained by monthly updates to the operating system. That means that it's yet another thing that you have to check for updates, isn't available on every machine, etc, etc. There's also a fair bit of it that can actually be done in T-SQL itself and so I do. I suppose that a part of the reason why I don't use it is that we're fairly well consolidated to keep license costs down and so I don't have to maintain hundreds of SQL Servers. Someone that does would probably find more utility in the DBATools than I. Still, it would be interesting to find out what happens when someone well versed in those tools are isn't allowed to use them (on certain government controlled secure systems, for example, although not a usual case).

Speaking of tools... OMG! The things people buy simply because they don't know what's available naturally. Backup software is one of those things that irks the hell out of me. People will buy uber-flexible software (initial cost and yearly maintenance fees can cost a small fortune if you have a lot of servers) and then use it generically because they don't have anything special going on in their databases. They don't realize how simple it is to write something to handle their generic needs because they don't actually know anything about T-SQL backups never mind what type of backups to make or when or anything on the subject of RPO or RTO. They also never test their backups as a restore because they end up assuming that the 3rd party software somehow makes everything bullet-proof.

Then there's monster software like Web Methods. One company that I've worked for bought it because the Enterprise Architect insisted that he didn't want to do ETL in SQL Server. In case you don't know what Web Methods is, it's like SSIS on steroids. So is the price and the learning curve. The company spend $250K on the initial purchase, found out it actually didn't do everything they wanted, spent another $100K to buy an add-on, and what did they end up with? A difficult to use, initial high cost with yearly maintenance fees, scheduler that calls T-SQL Stored Procedures to do <insert drum roll here> Bulk Inserts. <headdesk> <headdesk> <headdesk> <major face-palm>.

Heh... a lot of people think I'm a Luddite. I'm not. I just can't see spending a whole lot of money either purchasing software or learning to build software using the latest cool-kid software when everything you need is already available, is frequently easier to use, and is just as frequently better to use. People say "Well Jeff, just because you can do something in SQL Server doesn't mean you should". Thinking to myself "Why the hell not?", my normal retort is "Well dude, just because you can do something in SQL Server, doesn't mean you SHOULDN'T. Save yourself a shedload of money, lost time on learning curves, avoid the proverbial "Tower of Babel", and learn the tools you have".

Of course, almost everyone then walks away from the conversation shaking their head thinking "Jeff's a bloody Luddite" even after a demonstration of what can be done so easily and quickly because I know the tools that are already there.


--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
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

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
bkubicek
bkubicek
SSCrazy Eights
SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)

Group: General Forum Members
Points: 8220 Visits: 1012
Hi Jeff,

I do agree it doesn't really make sense to use a new tool just because it exists. Also, I do tend to lean toward if it can be done in t-sql then do it there. Still I am open if new tools, such as powershell, if they have a better way of doing things. I am familiar with some of the old things so it does give me a basis to judge if this new tool is the right one to use or not. That is a pretty funny comment about what is DOS? I have gotten that before as well. It seems like some people are a little more familiar with command prompt, but not always.

I guess because I do have a programming background as well, I don't mind the loops as much. Still I would always prefer a set based solution in t-sql if at all possible.

Anyway, you have certainly given some food for thought. Perhaps some new articles will come out of this discussion. The need to learn some of the old "ways" of doing things. Since sometimes the old "ways" are better.

Ben
qbrt
qbrt
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1641 Visits: 787
Jeff!!! You bloody Luddite!!!!! Tongue <walking away>
below86
below86
SSCertifiable
SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)SSCertifiable (7.1K reputation)

Group: General Forum Members
Points: 7132 Visits: 4699
I like to say "Just because you can do that in SSIS doesn't mean you should." I don't know how many data flow's I've looked at where I end up saying, "I could've done all of this in SQL." One example read in 3 tables, all on same server, did about 13 look up's, 3 splits of the data, 4 merges, 4 calls to VBscript before ending up in one SQL table. I was able to do the exact thing in about 600 lines of SQL(I'm sure i could reduce that if I wanted to). I did all of that just to prove it could be done. To me that SQL is a lot easier to understand and it's easier to maintain than that ugly data flow.

I'm not one to jump on the newest of latest and greatest of anything. I'm not going to stand in a line for some new phone or TV or other gadget or toy. I'm not going to stand in line just to be one of the first to see a movie. I guess I've always been that way, not just something I realized as I got older.

I'm also not going to go out and try and learn some new software or language if i'm not going to be using it. I'm one of those I need to be doing it to retain it. Now I haven't used COBOL in over 15 years, but I think I could still do it, just maybe not very well. The only reason I think that is because I coded in it for over 10 years. Now I learned some Java Script back in earl 2000's, but I haven't used it since that one project. So I doubt I could do much with that.

-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)

Group: General Forum Members
Points: 792020 Visits: 45937
bkubicek - Thursday, November 2, 2017 8:47 AM
Hi Jeff,

I do agree it doesn't really make sense to use a new tool just because it exists. Also, I do tend to lean toward if it can be done in t-sql then do it there. Still I am open if new tools, such as powershell, if they have a better way of doing things. I am familiar with some of the old things so it does give me a basis to judge if this new tool is the right one to use or not. That is a pretty funny comment about what is DOS? I have gotten that before as well. It seems like some people are a little more familiar with command prompt, but not always.

I guess because I do have a programming background as well, I don't mind the loops as much. Still I would always prefer a set based solution in t-sql if at all possible.

Anyway, you have certainly given some food for thought. Perhaps some new articles will come out of this discussion. The need to learn some of the old "ways" of doing things. Since sometimes the old "ways" are better.

Ben

Thanks for the feedback, Ben. Heh... oddly enough, I used to be an application programmer, as well, but that's why I hate loops so much. Wink


--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
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

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)SSC Guru (792K reputation)

Group: General Forum Members
Points: 792020 Visits: 45937
qbrt - Thursday, November 2, 2017 8:55 AM
Jeff!!! You bloody Luddite!!!!! Tongue <walking away>


BWAAA-HAAAA!!!! Now THAT'S FUNNY!

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
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

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search