October 8, 2013 at 8:25 am
Jeff Moden (10/8/2013)
Cadavre (10/7/2013)
simon.crick (10/7/2013)
I will probably get shot down again for saying this, but I believe people should stick to core technology and basic tecnhiques unless there is a very good reason for using exotic technology and advanced techniques.Why? Because no one person (even those of you who think you are expert experts) can ever know more than a tiny fraction of all the available technology and techniques, and if we all go off on our own paths following our own preferences for exotic technology and advanced techniques, then our systems will end up being a completely unmaintanable mish-mash of technologies and techniques.
I am not dumb. I have consistently achieved very high grades and won awards for outstanding achievement, etc., but the more I learn, the more I realize it is impossible to know everything, and therefore, out of consideration for our colleagues, we really ought to be sticking to core technology and basic techniques wherever possible.
Simon
I disagree completely. You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity. Then make sure that you document how the logic works.
I could certainly be wrong but I didn't take Simon's comment as avoiding the "best" technique. What I took it as is that a lot of people will take to what they know instead of learning what they need. For example, at a previous company, someone decided to parse some rather complicated files use PERL and DTS (is was a while back) to control things. This also required a split path in DTS that would later merge so there was some special code that needed to be written to remerge the paths. Since PERL couldn't actually do it all, they also wrote some Active-X and some VBS to complete the task of just getting a file ready for import. It took 45 minutes for each file and God forbid if they made a change because you needed to be an expert at Perl, DTS, Active-X, VBS, AND T-SQL to make a change. As Simon stated, it was a "a completely unmaintanable mish-mash of technologies and techniques". Enter SQLServer 2005 and the ability to write SQLCLR which only served to add yet another technology to the mish-mash. Some (and I don't use the word often) idiot actually wanted me to implement a CLR to do "Modulus" because he didn't take the time to learn that SQL Server has a modulus operator.
I think that's the kind of mess that I think Simon is talking about.
That's exactly the kind of mess I had in mind! 🙂
As so frequently happens, it turned out that some strong yet simple "core" knowledge of T-SQL solved 99% of the problem and a well formed splitter (you can probably guess which one I used) covered the other 1%. What used to take 45 minutes to just get a file ready for import now took only 2 minutes to stage, import, validate, and process 8 files to completion.
And that is what I think Simon is talking about when it comes to "core" and "simple" techologies. I don't believe he's suggesting avoidance of the "best" solution, which might involve some "complex" T-SQL. I think he's suggesting what I added to my signature line a couple of weeks ago. It's a play on words of a horribly overused phrase...
[font="Arial Black"]"Just because you CAN do something in SQL, doesn't mean you SHOULDN'T!" [/font]:-P
Like you say, core technology normally covers 99%+ of what we need to do, and nearly always does a very good job when used correctly. In the 1% of cases where there is no immediately obvious way to solve our problem using core technology, we should be very cautious about introducing exotic technology, as "core + X" can quickly degenerate into "core + X + Y + Z + P + Q + R", and before we know it, we've got another unmaintainable system. Most of the time, I think we are better off sacrificing a little bit of performance in order to avoid introducing exotic technology, as the overheads of maintaining the exotic technology will normally outweigh the benefits in the long run.
Simon
October 8, 2013 at 8:30 am
Jeff Moden (10/8/2013)
I have been known to stop an interview after just one super simple question and trust me on this... the question is just absolutely stupid simple.
Please share the Question 🙂 ?
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
October 8, 2013 at 8:36 am
Jeff Moden (10/8/2013)
That's a HUGE problem with most employers and recruiters. They ask people to rate themselves. How can an honest person who rates themselves as a good honest 6 or 7 compete with someone who actually doesn't know much of anything but rates themselves as a 9 or a 10?
Jeff But here is a small problem , if we quote ourselves 5 0r 6 (honestly) then it throws not good impression on interviewer.
Though i am totally agree with you that without certain parameters we cant judge/rate anybody.
So How much number should we rate to yuorself ? because as i go deep into some thing (in sql) , the more things comes up which are new to me .. and believe me it happens daily.
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
October 8, 2013 at 8:44 am
Jeff Moden (10/8/2013)
Gary Varga (10/7/2013)
simon.crick (10/7/2013)
Cadavre (10/7/2013)
simon.crick (10/7/2013)
I will probably get shot down again for saying this, but I believe people should stick to core technology and basic tecnhiques unless there is a very good reason for using exotic technology and advanced techniques.Why? Because no one person (even those of you who think you are expert experts) can ever know more than a tiny fraction of all the available technology and techniques, and if we all go off on our own paths following our own preferences for exotic technology and advanced techniques, then our systems will end up being a completely unmaintanable mish-mash of technologies and techniques.
I am not dumb. I have consistently achieved very high grades and won awards for outstanding achievement, etc., but the more I learn, the more I realize it is impossible to know everything, and therefore, out of consideration for our colleagues, we really ought to be sticking to core technology and basic techniques wherever possible.
Simon
I disagree completely. You go with the "best" technique (measurable by performance tests) for the job, regardless of complexity. Then make sure that you document how the logic works.
So if it works 1% faster but is 10 times as complex, you still go for the "advanced" technique?
Surely, that is over simplifying the argument to validate your point.
It is frequently said on these forums that "it depends" and your statistical scenario would most likely result in a no to the "advanced" technique in most cases, however, there are possibly scenarios where 1% would be considered of enough benefit. Particularly as a tactical solution to overcome system capacity limit issues.
Yet I agree with you in principle that all too often a complex solution is rolled out due to:
- role justification
- CV engineering
- curiosity
- post-training experimentation
- etc.
I guess this is another example of where professionalism should be applied alongside experience and expertise (and documenting skills ;-)).
Again, I could be wrong, but I believe you may have taken what Simon posted the wrong way. See my post to Cadavre above.
Actually, I sadly agree that all too often a complex solution is rolled out due to the reasons Gary listed above.
Unfortunately, it also seems that people who have lots of exotic technologies and advanced techniques listed on their CV often get promoted to senior positions faster than other people who could have solved the very same problems much more effectively using core technology and basic techniques.
This seems to be a viscious cycle in the computing industry, resulting in more-and-more complex systems that are less-and-less effective. To see that this is true, you only have to consider that computers are now at least 1000 times as powerful as they were in the mid-nineties, but how many of our systems have 1000 times the capacity/performance? Most of the extra power is being wasted on unnecessary complexity.
Simon
October 8, 2013 at 9:02 am
Jeff, I was both agreeing and disagreeing with Simon. It's never straightforward here 😉
Simon, totally agree. I have a CV full of skills that half of them I have used because others have selected them for reasons I strongly suspect are like the I ones listed above. I spent a good number of years as a C++ developer on a single platform. In my mind, then I was as near to an expert as I will ever be.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 8, 2013 at 3:23 pm
Bhuvnesh (10/8/2013)
Jeff Moden (10/8/2013)
That's a HUGE problem with most employers and recruiters. They ask people to rate themselves. How can an honest person who rates themselves as a good honest 6 or 7 compete with someone who actually doesn't know much of anything but rates themselves as a 9 or a 10?Jeff But here is a small problem , if we quote ourselves 5 0r 6 (honestly) then it throws not good impression on interviewer.
Though i am totally agree with you that without certain parameters we cant judge/rate anybody.
So How much number should we rate to yuorself ? because as i go deep into some thing (in sql) , the more things comes up which are new to me .. and believe me it happens daily.
For some of the reasons previously stated, I prefer to never rate myself on an overall rating basis. I just demonstrate what I can do and explain what I can't do yet but how I'd teach myself if the need arose.
To your point on honest rating, that's exactly the point I was trying to make. An honest person suffers if they rate themselves. The best thing to do is to simply explain what you've done and what you can do. Ultimately, it's the interviewer that will rate you.
I'll also say that when it comes to SQL Server, no single overall rating will suffice because it's just too big and has too many facets. It requires all walks to be part developer, part DBA, part BI, part ETL, part DW, and part mind-reader to name a few of the skills. The job at hand determines which skills will come into play the most and the purpose of the interview is to determine if the candidate has the skills in the areas needed and whether there's going to be a culteral and personality fit.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2013 at 3:36 pm
logitestus (10/8/2013)
I run into this type of problem everywhere I have worked. Someone states "this is the way to do it" because they saw X% faster performance. As my group's resident "expert" on SQL, I have had to teach multiple "lunch-n-learns" on SQL performance tuning. Before this everyone based their SQL perf on how fast the query was (and sadly some still do). The problem with this was/is the test set of data is maybe 100 rows at best. In production we get at least 10-100 times that. Then they wonder, why isn't my query/view/stored proc running faster.
Very well done on the "lunch-n-learns". It's not only a powerful way to teach people but its also a way for folks to get closer to the DBA and more easily understand the reasons for our individual and shared mantras.
I also have to agree with Jeff on the hodge-podge of technologies people use. A few of our customers use a Python-scripted tool which utilizes a .Net 1.1 custom executable (source no longer exists) to import data from a flat file to a SQL 2005/2008 database. The Python experts always say its the .Net or the database. The .Net folks blame Python or usually the database. I've been forced to become, at least slightly proficient, in all of those technologies just so I can prove that its a combination of all 3.
While everyone is blaming everyone else, my normal fix for such a hodge-podge of cruddy code is to simply can it all and start over. While that sounds a bit spooky, I've frequently found a total rewrite to be a quicker solution than to try to patch already horrible code. It also stops the silly bickering by the other folks because not only has the problem been fixed, but it's also not their code anymore.
They can't shoot pool if I take their stick away. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2013 at 5:51 pm
Jeff Moden (10/8/2013)
logitestus (10/8/2013)
I run into this type of problem everywhere I have worked. Someone states "this is the way to do it" because they saw X% faster performance. As my group's resident "expert" on SQL, I have had to teach multiple "lunch-n-learns" on SQL performance tuning. Before this everyone based their SQL perf on how fast the query was (and sadly some still do). The problem with this was/is the test set of data is maybe 100 rows at best. In production we get at least 10-100 times that. Then they wonder, why isn't my query/view/stored proc running faster.Very well done on the "lunch-n-learns". It's not only a powerful way to teach people but its also a way for folks to get closer to the DBA and more easily understand the reasons for our individual and shared mantras.
I also have to agree with Jeff on the hodge-podge of technologies people use. A few of our customers use a Python-scripted tool which utilizes a .Net 1.1 custom executable (source no longer exists) to import data from a flat file to a SQL 2005/2008 database. The Python experts always say its the .Net or the database. The .Net folks blame Python or usually the database. I've been forced to become, at least slightly proficient, in all of those technologies just so I can prove that its a combination of all 3.
While everyone is blaming everyone else, my normal fix for such a hodge-podge of cruddy code is to simply can it all and start over. While that sounds a bit spooky, I've frequently found a total rewrite to be a quicker solution than to try to patch already horrible code. It also stops the silly bickering by the other folks because not only has the problem been fixed, but it's also not their code anymore.
They can't shoot pool if I take their stick away. 😀
While I don't necessarily disagree with the discussion - it's important to remember that complex is often a point of view. Jeff , what you call simple took me 6 months of decomposing to even comprehend the first time I saw it. The tally table tricks, quirky update, and command of BCP is stuff I simply just don't use enough to stay as good on those as I'd like to. Simple is fine thing to strive for, but you can't always code to the lowest common denominator on the team.
I think there needs to be a rationalization of what tools to use, but someone showing up with new skills and tools MIGHT actually have a point every once in a while. Shutting down to new options can be just as problematic as tilting after the latest shiny windmill on the horizon.
I think it's okay to try out new things: just be clear about it, and make sure everyone who might have to come in contact with it is socialized in the new tool and knows how to support it OR to shoot heavy thing in your direction when it does break.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 8, 2013 at 10:40 pm
Matt Miller (#4) (10/8/2013)
While I don't necessarily disagree with the discussion - it's important to remember that complex is often a point of view. Jeff , what you call simple took me 6 months of decomposing to even comprehend the first time I saw it. The tally table tricks, quirky update, and command of BCP is stuff I simply just don't use enough to stay as good on those as I'd like to.
I'm not sure where you're going with that. Like anyone else, more than 99% of what I do or have other people do revolves only around the "core"/"simple" knowledge that we've been speaking of and none of that is "complex".
Ironically, what I do find is that many people actually make things more complex by not knowing the simple core technology, and I do mean simple. For example, how many times have you and I seen people use a While loop to update one table from another one row at a time simply because they don't know the core technology of how to correctly form a much more simple joined UPDATE even at simple ANSI levels? How many times have you and I seen people use complex IF logic in their stored procedures because the don't understand the simple core logic of CASE fuctionality?
Simple is fine thing to strive for, but you can't always code to the lowest common denominator on the team.
Absolutely agreed on that but don't confuse "simple" with coding to the lowest common denominator. That's not the "simple" I'm talking about. But you also don't need to write a CLR to do something "simple" like generating random integers.
Even for non-core knowledge, how hard is it to learn what a BCP format file is to import a fixed-field file usig BULK INSERT? Heh... and don't think for a minute that I have what a BCP format file needs to look like memorized. I have to look it up every time because, like you, I don't have to do it all that often. But that brings us to another "core" technology that's terribly overlooked. It's in "Books Online" and more than half the "developers" that I've interviewed don't even know what that is.
I think there needs to be a rationalization of what tools to use, but someone showing up with new skills and tools MIGHT actually have a point every once in a while. Shutting down to new options can be just as problematic as tilting after the latest shiny windmill on the horizon.
I think it's okay to try out new things: just be clear about it, and make sure everyone who might have to come in contact with it is socialized in the new tool and knows how to support it OR to shoot heavy thing in your direction when it does break.
I absolutely agree and I'm always interested in new skills and tools but if you suggest to me (more true examples) that I need a CLR to generate random integers or "universal triggers" or that I need to write a PowerShell script to do centralized backups even for a thousand servers, I'm going to shut that notion down right away.
Shifting gears, it's also a two way street. Lets say that someone comes in with a great idea using a "new" technology (PowerShell!) against the database and I like the idea a whole lot. If I can pull the same thing off in T-SQL using "core" technology or even an "exotic" technique in T-SQL like the Tally Table, why is it that the lecture of "Well, just because you can do something in T-SQL, doesn't mean you should" always seems to rise to the surface? If I'm doing something with the database and I can do it in T-SQL, why shouldn't I? You and I saw this when you and I were having fun with our friendly but very competative (and very enjoyable, I might add) Regex races many years ago.
Then there's the "manager great idea". I won't say what program we bought or what it does but it cost about the same as paying my salary for more than 2 years. It was a great idea except that it cost too much on initial investment, has a very steep learning curve (it took people almost 2 years to get a decent grip on it and they still haven't figured out some of the high profile "gotcha's"), is difficult to use, and even though it has a huge and nasty impact on the SQL Servers, it's scheduled outside of SQL Server where I have absolutely no control over it. It would have been an easy thing to do in SQL Server but, once again, I had to listen to the same tired old saw of "Just because you can do it in SQL Server, doesn't mean you should". This is the type of technology "improvement" that I've seen way to many times and that, given the opportunity, would have summarily shut down, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 8, 2013 at 11:24 pm
Jeff Moden (10/8/2013)
Matt Miller (#4) (10/8/2013)
While I don't necessarily disagree with the discussion - it's important to remember that complex is often a point of view. Jeff , what you call simple took me 6 months of decomposing to even comprehend the first time I saw it. The tally table tricks, quirky update, and command of BCP is stuff I simply just don't use enough to stay as good on those as I'd like to.I'm not sure where you're going with that. Like anyone else, more than 99% of what I do or have other people do revolves only around the "core"/"simple" knowledge that we've been speaking of and none of that is "complex".
Ironically, what I do find is that many people actually make things more complex by not knowing the simple core technology, and I do mean simple. For example, how many times have you and I seen people use a While loop to update one table from another one row at a time simply because they don't know the core technology of how to correctly form a much more simple joined UPDATE even at simple ANSI levels? How many times have you and I seen people use complex IF logic in their stored procedures because the don't understand the simple core logic of CASE fuctionality?
Simple is fine thing to strive for, but you can't always code to the lowest common denominator on the team.
Absolutely agreed on that but don't confuse "simple" with coding to the lowest common denominator. That's not the "simple" I'm talking about. But you also don't need to write a CLR to do something "simple" like generating random integers.
Even for non-core knowledge, how hard is it to learn what a BCP format file is to import a fixed-field file usig BULK INSERT? Heh... and don't think for a minute that I have what a BCP format file needs to look like memorized. I have to look it up every time because, like you, I don't have to do it all that often. But that brings us to another "core" technology that's terribly overlooked. It's in "Books Online" and more than half the "developers" that I've interviewed don't even know what that is.
Heh - the only place I was really going was that "simple" has been used against me too many times, as in when "simple" = nested cursor + GOTO + RBAR hell, and anything ELSE = fancy/exotic/etc.... Simple is just a much too generic marketing term than can be twisted just about any darn direction you like.
I've always come from the "right tool for the right job" camp, so don't worry I have not strayed from using the techniques that work. That particular phrase however has been the bane of my recent existence, so I prefer to push for the better answer as you have already provided.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Viewing 10 posts - 31 through 39 (of 39 total)
You must be logged in to reply to this topic. Login to reply