December 26, 2017 at 10:45 am
David.Poole - Tuesday, December 26, 2017 9:30 AMJeff Moden - Tuesday, December 26, 2017 6:35 AMHeh... That's a part of the point I tried to make... I wonder how much of that could easily be done using only T-SQL and a bit of DOS... especially when it comes to the 4 ETL tools that you ended up preferring over SSIS. 😉
It boils down to what you really need.
Yes it does... normally the only thing needed is something that works correctly and fast. If you know the tools natively available in SQL Server, it frequently means less money, faster problem resolution, permanent supportability on any SQL Server box, and not having to learn how to use yet another tool. For example, SQLPS anyone? Rumor has it that's no longer supported.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 26, 2017 at 11:20 am
Jeff Moden - Tuesday, December 26, 2017 10:45 AMDavid.Poole - Tuesday, December 26, 2017 9:30 AMJeff Moden - Tuesday, December 26, 2017 6:35 AMHeh... That's a part of the point I tried to make... I wonder how much of that could easily be done using only T-SQL and a bit of DOS... especially when it comes to the 4 ETL tools that you ended up preferring over SSIS. 😉
It boils down to what you really need.
Yes it does... normally the only thing needed is something that works correctly and fast. If you know the tools natively available in SQL Server, it frequently means less money, faster problem resolution, permanent supportability on any SQL Server box, and not having to learn how to use yet another tool. For example, SQLPS anyone? Rumor has it that's no longer supported.
Well, that was quick. It's deprecated according to https://docs.microsoft.com/en-us/sql/tools/sqlps-utility.
December 27, 2017 at 9:32 am
If you are a 'one trick pony' when it comes to tools and tech then over time your designs are increasingly likely to look like Rube Goldberg cartoons. You don't need to be an expert in every tool but you should at least be aware of their strengths and weaknesses, at least the popular flavors or the ones used in your shop.
December 27, 2017 at 10:46 am
HighPlainsDBA - Wednesday, December 27, 2017 9:32 AMIf you are a 'one trick pony' when it comes to tools and tech then over time your designs are increasingly likely to look like Rube Goldberg cartoons. You don't need to be an expert in every tool but you should at least be aware of their strengths and weaknesses, at least the popular flavors or the ones used in your shop.
When it comes to databases, I've found that all the supposed spiffy tools and tech that a lot of people resort to (mostly because they don't know the built-in/native capabilities) is actually more responsible for designs that look like a "Rube Goldberg Cartoon" than anything else. People say things like "one trick pony" and "To a hammer, everything is a nail" without ever realizing that when all you're trying to do is drive a nail, you should probably use some form of hammer.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2017 at 11:19 am
Jeff Moden - Wednesday, December 27, 2017 10:46 AMHighPlainsDBA - Wednesday, December 27, 2017 9:32 AMIf you are a 'one trick pony' when it comes to tools and tech then over time your designs are increasingly likely to look like Rube Goldberg cartoons. You don't need to be an expert in every tool but you should at least be aware of their strengths and weaknesses, at least the popular flavors or the ones used in your shop.When it comes to databases, I've found that all the supposed spiffy tools and tech that a lot of people resort to (mostly because they don't know the built-in/native capabilities) is actually more responsible for designs that look like a "Rube Goldberg Cartoon" than anything else. People say things like "one trick pony" and "To a hammer, everything is a nail" without ever realizing that when all you're trying to do is drive a nail, you should probably use some form of hammer.
I agree with that, the point I'm trying to make is that if you don't invest a little time at expanding your toolbox or at least browse what is currently out there your solutions will probably get messy as your world expands. For example, a few years ago I needed to hook into a web API to pull some metrics from a web site and load a database with it. Building a solution around a PoSh Invoke-WebRequest commandlet and a .NET System.Data.SqlClient.SqlConnection object let me do it in about 50 lines of code running as a SQL Agent job. I suspect I couldn't get away with such brevity with the CLR or T-SQL extended stored procedures. Conversely, I once had a senior developer hand me a 7 page T-SQL 'solution' for the processing of some of the barcodes at our warehouses and there wasn't a single table referenced anywhere. It was all string processing.
I do have an almost irrational dislike of the Entity Framework though I'm not sure it qualifies as a tool.
December 27, 2017 at 11:36 am
Perhaps we should turn this discussion on its head. Is old stuff worth teaching? I think that's the important question because it means those of us who have walked up hill both ways have a duty to teach the old stuff worth teaching.
Teach once, learn twice
December 27, 2017 at 11:46 am
HighPlainsDBA - Wednesday, December 27, 2017 11:19 AMJeff Moden - Wednesday, December 27, 2017 10:46 AMHighPlainsDBA - Wednesday, December 27, 2017 9:32 AMIf you are a 'one trick pony' when it comes to tools and tech then over time your designs are increasingly likely to look like Rube Goldberg cartoons. You don't need to be an expert in every tool but you should at least be aware of their strengths and weaknesses, at least the popular flavors or the ones used in your shop.When it comes to databases, I've found that all the supposed spiffy tools and tech that a lot of people resort to (mostly because they don't know the built-in/native capabilities) is actually more responsible for designs that look like a "Rube Goldberg Cartoon" than anything else. People say things like "one trick pony" and "To a hammer, everything is a nail" without ever realizing that when all you're trying to do is drive a nail, you should probably use some form of hammer.
I agree with that, the point I'm trying to make is that if you don't invest a little time at expanding your toolbox or at least browse what is currently out there your solutions will probably get messy as your world expands. For example, a few years ago I needed to hook into a web API to pull some metrics from a web site and load a database with it. Building a solution around a PoSh Invoke-WebRequest commandlet and a .NET System.Data.SqlClient.SqlConnection object let me do it in about 50 lines of code running as a SQL Agent job. I suspect I couldn't get away with such brevity with the CLR or T-SQL extended stored procedures. Conversely, I once had a senior developer hand me a 7 page T-SQL 'solution' for the processing of some of the barcodes at our warehouses and there wasn't a single table referenced anywhere. It was all string processing.
I do have an almost irrational dislike of the Entity Framework though I'm not sure it qualifies as a tool.
Understood but my whole point is that a great deal of people haven't checked their current tool box well enough to even know if they should be looking for a different tool. PoSh is a particular sore point for me. While I agree that it has some great capabilities, look at the ridiculous "too cool for school" code that came out nearly as soon as PoSh did. People thought, for example, that it would be really cool to write centralized backups using PoSh without realizing what happens to the log files of all those servers if the centralized solution failed. One of the supposed greatest things to happen to PoSh was the creation of SQLPS... it just went into the "no longer supported" mode. Rube's "mousetrap" caught the builders of the "better" mouse trap. 😉
This particular cycle isn't limited to just PoSh but neither of us has the time to list all of the "shiny new objects" that were created and used and sometimes quickly abandoned. Most of the problems and new stuff seems to be to try to, indirectly or directly, support people that shouldn't be allowed near a database. That marketing strategy helps sell product but, with some truly innovative but rare exceptions, change is inevitable but change for the better is not. I also appreciate you 7 page code example but that's a part of what I'm talking about, as well. Someone that actually knows the tools at hand would be appalled at 7 pages of string handling and could probably do it a whole lot more efficiently regardless of which language was used for the solution.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2017 at 12:41 pm
Jeff Moden - Wednesday, December 27, 2017 11:46 AMHighPlainsDBA - Wednesday, December 27, 2017 11:19 AMJeff Moden - Wednesday, December 27, 2017 10:46 AMHighPlainsDBA - Wednesday, December 27, 2017 9:32 AMIf you are a 'one trick pony' when it comes to tools and tech then over time your designs are increasingly likely to look like Rube Goldberg cartoons. You don't need to be an expert in every tool but you should at least be aware of their strengths and weaknesses, at least the popular flavors or the ones used in your shop.When it comes to databases, I've found that all the supposed spiffy tools and tech that a lot of people resort to (mostly because they don't know the built-in/native capabilities) is actually more responsible for designs that look like a "Rube Goldberg Cartoon" than anything else. People say things like "one trick pony" and "To a hammer, everything is a nail" without ever realizing that when all you're trying to do is drive a nail, you should probably use some form of hammer.
I agree with that, the point I'm trying to make is that if you don't invest a little time at expanding your toolbox or at least browse what is currently out there your solutions will probably get messy as your world expands. For example, a few years ago I needed to hook into a web API to pull some metrics from a web site and load a database with it. Building a solution around a PoSh Invoke-WebRequest commandlet and a .NET System.Data.SqlClient.SqlConnection object let me do it in about 50 lines of code running as a SQL Agent job. I suspect I couldn't get away with such brevity with the CLR or T-SQL extended stored procedures. Conversely, I once had a senior developer hand me a 7 page T-SQL 'solution' for the processing of some of the barcodes at our warehouses and there wasn't a single table referenced anywhere. It was all string processing.
I do have an almost irrational dislike of the Entity Framework though I'm not sure it qualifies as a tool.Understood but my whole point is that a great deal of people haven't checked their current tool box well enough to even know if they should be looking for a different tool. PoSh is a particular sore point for me. While I agree that it has some great capabilities, look at the ridiculous "too cool for school" code that came out nearly as soon as PoSh did. People thought, for example, that it would be really cool to write centralized backups using PoSh without realizing what happens to the log files of all those servers if the centralized solution failed. One of the supposed greatest things to happen to PoSh was the creation of SQLPS... it just went into the "no longer supported" mode. Rube's "mousetrap" caught the builders of the "better" mouse trap. 😉
This particular cycle isn't limited to just PoSh but neither of us has the time to list all of the "shiny new objects" that were created and used and sometimes quickly abandoned. Most of the problems and new stuff seems to be to try to, indirectly or directly, support people that shouldn't be allowed near a database. That marketing strategy helps sell product but, with some truly innovative but rare exceptions, change is inevitable but change for the better is not. I also appreciate you 7 page code example but that's a part of what I'm talking about, as well. Someone that actually knows the tools at hand would be appalled at 7 pages of string handling and could probably do it a whole lot more efficiently regardless of which language was used for the solution.
You won't get much of an argument out of me regarding IT people not knowing enough about the tools they use. I try to make the tool(s) fit the solution and not the other way around (or at least actively try to avoid it), but I can't do that very well if I exclusively focus on T-SQL. Right? As a DBA we are asked to solve lots of technical problems that often cross functional boundaries and find ourselves outside of our comfort zone. I like to be armed with more than just T-SQL but I agree that I should first have a clue how to use the primary product before I try to get too fancy. 🙂
As for PoSh I have really only used it a few times for some edge cases and I certainly wouldn't advise using it for data processing. It's like glue for me.
December 27, 2017 at 1:50 pm
A new tool is released and its purpose isn't widely known. To compensate the vendor tries to give an example to which the target audience can relate. Unfortunately the examples are likely to be contrived and not really what the tool was intended for.
Add in the sort of decision maker who just reads white papers and attends vendor presentations. Then throw in to the mix the sort of people who copy/paste Stack overflow without validating it.
Some of these tools do have benefits but people don't know what uses to avoid and which to adopt. Particularly for new tools where do you find the trusted sources of expertise?
Some tools are of their time. Container technology has been around for over a decade but today through Docker & Kubernetes are capturing hearts and minds.
Remember when Garbage Collection was the world's stupidest idea? Now it's essential for .net and JVM programming.
December 27, 2017 at 2:31 pm
"When database professionals don’t have solid T-SQL skills they can get into trouble quickly if their tools fail or if they start a new job that doesn’t have the tools that they had previously used. "
Well, within reason I think the above is definitely true. I'm not saying that everyone needs to go back to the days of Assembler Language, RPG, Cobol, with hierarchical databases or the like. However, I feel from personal experience that that background does in fact give one a better understanding of the modern tools and an intuition for how they accomplish what they do in the background for you.
I have always felt that a sound basis in SQL is THE most critical skill for db professionals. The thorough understanding of how SQL works is going to provide one with understanding of how to build the best structures for various solutions, how to develop the best code, and the necessary ability to address performance issues.
And just an aside here, don't ever assume that because the tool is newer it is also better. Those tools had to be developed by people with some sort of skills which may or may not be the best.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
December 27, 2017 at 2:55 pm
David.Poole - Wednesday, December 27, 2017 1:50 PMA new tool is released and its purpose isn't widely known. To compensate the vendor tries to give an example to which the target audience can relate. Unfortunately the examples are likely to be contrived and not really what the tool was intended for.
Add in the sort of decision maker who just reads white papers and attends vendor presentations. Then throw in to the mix the sort of people who copy/paste Stack overflow without validating it.
Some of these tools do have benefits but people don't know what uses to avoid and which to adopt. Particularly for new tools where do you find the trusted sources of expertise?
Some tools are of their time. Container technology has been around for over a decade but today through Docker & Kubernetes are capturing hearts and minds.
Remember when Garbage Collection was the world's stupidest idea? Now it's essential for .net and JVM programming.
Ahhh... Garbage Collection... I can remember when that idea was sure to elicit a furrowed brow and squinted eyes from your fellow programmer back in the day. 🙂 We used to describe Java as 'C on training wheels' but to be fair, I think of all of the memory leak problems it seems to have helped clean up. Then again maybe it just contributed to enabling crappier programming habits by hiding their faults better?
December 28, 2017 at 10:09 am
David.Poole - Wednesday, December 27, 2017 11:36 AMPerhaps we should turn this discussion on its head. Is old stuff worth teaching? I think that's the important question because it means those of us who have walked up hill both ways have a duty to teach the old stuff worth teaching.
Teach once, learn twice
That is an interesting question. Put that way, I see less reason to learn old stuff. From my point of view, why would I want to pay anyone to learn old stuff? Let me give you an example. Back in the late 1990's, early 2000's I was on a team that wrote a lot of VB6 code. Back then, learning all of the tips and tricks I could was vital. I bought books on VB6 coding. I took classes on VB6 coding. I learned as much as I possibly could on VB6 coding.
But today if you were to try and sell me a $50 book on VB6 coding, I'd laugh in your face. I wouldn't spend $5 on a VB6 book today. I don't want to do VB6 coding at all. I couldn't care less about it. Wasting my time doing any VB6 coding today is almost a sure way of getting labeled as someone who can do "that old stuff" and never be allowed to work on anything new, interesting or would advance my career.
Yes David, I believe you're asked a very important question that helps to clarify whether or not its worth one's time to learn some old stuff. The way I see it now is that if the "old stuff", whatever it is, may still be highly applicable, then it's worth learning. Otherwise, I won't consider it.
Rod
December 28, 2017 at 10:40 am
Again, the desire to avoid a subject lest you get shackled to it is an interesting point.
I find that to be good at something you have to immerse yourself in it. Time and energy being finite immersing yourself in an obscure or dieing niche is highly undesirable.
I know a few retired COBOL programmers who love being able to supplement their pensions with a skill where supply is dwindling faster than demand
December 28, 2017 at 11:01 am
David.Poole - Thursday, December 28, 2017 10:40 AMAgain, the desire to avoid a subject lest you get shackled to it is an interesting point.
I find that to be good at something you have to immerse yourself in it. Time and energy being finite immersing yourself in an obscure or dieing niche is highly undesirable.
I know a few retired COBOL programmers who love being able to supplement their pensions with a skill where supply is dwindling faster than demand
Too bad my COBOL skills aren't in the mainframe environment but the minicomputer environment. I don't know anything about CICS or JCL.
December 28, 2017 at 11:09 am
Lynn Pettis - Thursday, December 28, 2017 11:01 AMDavid.Poole - Thursday, December 28, 2017 10:40 AMAgain, the desire to avoid a subject lest you get shackled to it is an interesting point.
I find that to be good at something you have to immerse yourself in it. Time and energy being finite immersing yourself in an obscure or dieing niche is highly undesirable.
I know a few retired COBOL programmers who love being able to supplement their pensions with a skill where supply is dwindling faster than demandToo bad my COBOL skills aren't in the mainframe environment but the minicomputer environment. I don't know anything about CICS or JCL.
I know COBOL on a mainframe...from the 1980s. Granted, I don't know if the mainframe environment hasn't changed much since then, but I just don't have the interest or time to deal with it unless forced. It did come in handy a few years ago when I had to talk a company (we traded data with) through reading her JCL to prove the data file I delivered was valid and that it was their FTP program that was destroying it during the transfer. I must admit it was difficult to remember some of it, but we got through it. The sad part was that she couldn't do it herself on her own mainframe. I'm thankful I had the experience necessary to help, but I really don't want to work in that environment full time.
Viewing 15 posts - 16 through 30 (of 44 total)
You must be logged in to reply to this topic. Login to reply