September 7, 2009 at 9:55 pm
Comments posted to this topic are about the item Using the Best
September 7, 2009 at 10:39 pm
Aye... you've hit a sore spot for me. I love new things but only when they actually are the "best" for the job. When 2k5 first came out, a lot of folks simply lost their minds and started writing everything with Recursive CTE's and CLR's without testing what the impact on performance and scalability actually may be. The same has happened with many of the new features in 2k8... some have been inappropriately used just because they're new even if they are not the best thing for a particular task.
Shifting gears abit, I just love it when people post two pieces of code and ask, "Which will be faster?" It's a real challenge to hold back what I really think about their question, their skill (lack of), and their personality (lazy or maybe even stupid) when I see something like that. The good part is, at least they're asking. A lot of folks don't even care enough or know enough to ask never mind how to find out on their own.
The other thing that perplexes me is that it's frequently very easy to surpass the simple "good enough" mark in code with some code that stands a chance of being scalable. While I understand the idea that the "absolute best" (differences sometimes measured in milliseconds compared to other methods) can be counter productive, people justify the use of RBAR methods simply because they were told the task they're writing against will be permanently limited in scope... in other words, they "think" they're doing what is best but they're really just building technical dept that will someday need to be paid despite the promises of low scope.
To sum things up, the "Best" may only be the best for the individual (as perceived by the individual) and not for the system. The really big problem is, there are a lot of people that don't understand , don't know, and/or don't care about what's really "the best".
--Jeff Moden
Change is inevitable... Change for the better is not.
September 8, 2009 at 3:34 am
Steve, Jeff,
I see your points on asking an expert and understand what you are saying but speaking as someone who is, on balance, a user of forums rather than a contributor I feel you may be a little biased in your comments. Buck Woody's blog is quoted as saying 'the best' depends on circumstances. Some of us are in that predicament when it comes to training, knowledge, time and resources. Sure I would love to spend time testing 8 different scenarios for a procedure before I deploy, or running it against a database with indexes in different configurations and so forth but the time I have means this is in the rare to non-existant category. If I can quickly ask a question (sic Twitter, SQLServerCentral, SSWUG, SimpleTalk, ServerFault, StackOverflow etc) and get a 80%-90% accurate in most scenarios response then that is what I have to go with.
This may be down to my lack of intelligence, skill, experience, time to test, employers benevolence towards training and attitude to community input etc etc but it isnt necessarily through a lack of interest in the subject and the desire to know more. I have been a DBA for some time now and I have, to my regret, a flatter learning curve that a lot of others. I cant help this but I would hope that I dont ask the same question twice and that I scan through forums for an answer before I take up the generous and indeed most welcome support of others by asking a repeat question.
The likes of myself may not actually have any aspirations to become an expert, just to do a good job and help our companies thrive as best they can.
- I ask a plumber for advice about my heating system because they are an expert and I dont want to make a mess of fixing something and then get boiling water coming out of the pipework. My wife would be very upset with me and we would have to go shopping for new furniture AND a plumber to put it right.
- I ask a SQL expert for advice about (insert SQL issue here) because they are an expert and I dont want to make a mess of fixing something and then get the data corrupt/users phoning me about a slow system. My empoyer would be very upset with me and he would have to go shopping for new DBA and a consultant to put it right.
This isnt meant as any sort of rant, I am just trying to say that sometimes the little guy may act stupid but in many cases this is not on purpose. On their/my behalf can I say that we are truly grateful for you experts that spend so much time helping us out.
Regards
Jonathan
September 8, 2009 at 8:52 am
... and we've learned to love the taste of cold pig at high velocity...:-P
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 8, 2009 at 9:09 am
You definitely want advice, but you can't necessarily expect it to be the best for your system. Asking for someone else how to do something on a forum/twitter/etc., doesn't absolve you from doing a little testing.
I agree that you can't test all scenarios, but that doesn't mean that you also test none of them, or one. You ought to at least gather metrics on the solution you implement so that you can decide at some point what's the best. It's OK not to want to be an expert, but you want to be competent, which is more than just taking advice.
In the case of a plumber, you definitely want to ask his/her advice, but then you need to educate yourself a little as well to try and decide if it's really good advice. There's a plumber out there that was the worst in his apprenticeship/class, just like a doctor. A little questioning, judgment, and testing on your part is a good idea.
September 8, 2009 at 9:17 am
If we're talking about specifying a database or server design, there are principles, although I don't know if I can tell you what they are. There's material in the SQL Server DBA courses on the topic, which is easily forgotten of course.
But many of us don't have the luxury of test-driving different system designs, or else we are in the happy position of scoring a salary where setting aside time to test the configuration's performance costs more than just buying the biggest one in the catalogue.
However, if you're going to buy not 1 but 1000 of those servers, the economics are different there. Maybe buy 50 as the pilot systems, if they don't work out and you toss them then you only spent 105% of the budget, it's survivable...
September 8, 2009 at 9:51 am
I have to admit, I don't test drivers on my computers to see which is "best". I download the most current, and if it becomes unstable, I revert to the last stable build.
When I'm designing a database, I simply go for the highest level of normalization that I can get with that data, and if that turns into a problem, I fix the specific issues that come up. I don't build a dozen designs and spend a huge amount of time testing each. I go with what study and experience tells me should work well, and then deviate when I find specific issues, and incorporate that deviation into my experience in case something similar comes up again later. (After all, that's what experience is.)
When I'm writing code, I start out with what I know will work. Then, if it doesn't work well, I modify to fix specific issues. Again, study and experience are enough to tell me where to start, then I add to the experience if I need to.
Just like I don't bake bread a dozen different ways to see which one ends up the most edible. I follow the directions.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 8, 2009 at 11:57 am
But many of us don't have the luxury of test-driving different system designs, or else we are in the happy position of scoring a salary where setting aside time to test the configuration's performance costs more than just buying the biggest one in the catalogue.
Many of us work in smaller shops and DBA is one of the hats that we might wear in a given work day. So you won't see us jumping on the latest and greatest systems or drivers. We'll watch the pioneers and see which arrows end up in their butts! 😛
September 9, 2009 at 1:31 am
jonathan allen (9/8/2009)
Buck Woody's blog is quoted as saying 'the best' depends on circumstances. Some of us are in that predicament when it comes to training, knowledge, time and resources.
Thanks for the feedback, Jonathan.
I don't know Buck Woody personally so I can't speak for him. While I agree that "the best" frequently depends on cirucumstances, it should never include code that is intentionally written to be slow. Writing any form of RBAR other than certain control-of-flow code is intentionally written to be slow. The tired old saw of not having enough training or knowledge simply isn't acceptable. If folks know that they'll be writing SQL, they should spend some time learning it even if it means learning it on their own time because their job depends on their knowledge. Equipped with such knowledge, folkks won't have to do 8 different tests... you'll already know the right way to do it which will also save on time and resources both in the short run and the long run.
For those folks that balk at the idea of spending time learning something about their livelihood on their own time... prepare to be left behind (ie. Unemployed) by the folks that don't balk.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 9, 2009 at 11:08 am
jonathan allen (9/8/2009)
Steve, Jeff,I see your points on asking an expert and understand what you are saying but speaking as someone who is, on balance, a user of forums rather than a contributor I feel you may be a little biased in your comments. Buck Woody's blog is quoted as saying 'the best' depends on circumstances. Some of us are in that predicament when it comes to training, knowledge, time and resources. Sure I would love to spend time testing 8 different scenarios for a procedure before I deploy, or running it against a database with indexes in different configurations and so forth but the time I have means this is in the rare to non-existant category. If I can quickly ask a question (sic Twitter, SQLServerCentral, SSWUG, SimpleTalk, ServerFault, StackOverflow etc) and get a 80%-90% accurate in most scenarios response then that is what I have to go with.
This may be down to my lack of intelligence, skill, experience, time to test, employers benevolence towards training and attitude to community input etc etc but it isnt necessarily through a lack of interest in the subject and the desire to know more. I have been a DBA for some time now and I have, to my regret, a flatter learning curve that a lot of others. I cant help this but I would hope that I dont ask the same question twice and that I scan through forums for an answer before I take up the generous and indeed most welcome support of others by asking a repeat question.
The likes of myself may not actually have any aspirations to become an expert, just to do a good job and help our companies thrive as best they can.
- I ask a plumber for advice about my heating system because they are an expert and I dont want to make a mess of fixing something and then get boiling water coming out of the pipework. My wife would be very upset with me and we would have to go shopping for new furniture AND a plumber to put it right.
- I ask a SQL expert for advice about (insert SQL issue here) because they are an expert and I dont want to make a mess of fixing something and then get the data corrupt/users phoning me about a slow system. My empoyer would be very upset with me and he would have to go shopping for new DBA and a consultant to put it right.
This isnt meant as any sort of rant, I am just trying to say that sometimes the little guy may act stupid but in many cases this is not on purpose. On their/my behalf can I say that we are truly grateful for you experts that spend so much time helping us out.
Regards
Jonathan
I agree with Jonathan. Another reason you might "act stupid" or ask what seems to be obvious is that you are coming at the question from a different perspective or come from a training situation in which that aspect was not covered.
September 9, 2009 at 1:02 pm
Actually, we've gotten a bit off track. I don't mind people asking questions on forums... in fact, I recommend it because there are so many great folks out there who love to share their knowledge and experience.
But, to continue the metaphor...
When you're writing SQL (or any other programming language), you're not asking the plumber for advice on the heating system. Rather, you're taking the place of the plumber. If you don't know how to sweat pipes nor prepare the pipe joints for sweating and you have no intention of taking the time to do it right, then you shouldn't be doing the work. If you do, you'll either end up with leaky pipes or a cold solder joint that will blow apart unexpectedly when the pressure on the system changes. If you use aggressive acid flux (RBAR) instead of the more benign version recommended for such pipes just because you don’t have the time to find the correct flux (Set Based), then you'll run into similar problems.
I’m not suggesting that everyone who needs to sweat a pipe needs to take the time to become an absolute Master Plumber, but they should at least know enough to keep from causing damage whether that damage happen immediately or sometime down the road.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 9, 2009 at 1:26 pm
Good analogy, Jeff.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 9, 2009 at 1:41 pm
In smaller shops, you can't always use the "very best" due to budget or time. You use the best you can, given the circumstances. This doesn't mean that you don't research or educate one's self, it means that you may have to deal with different constraints than a large shop with a larger budget and staff. This means that you are more conservative in your approaches to a problem, not that you don't avail yourself of BOL and other easy to check resources.
September 11, 2009 at 6:44 am
Jeff Moden (9/9/2009)
jonathan allen (9/8/2009)
Buck Woody's blog is quoted as saying 'the best' depends on circumstances. Some of us are in that predicament when it comes to training, knowledge, time and resources.Thanks for the feedback, Jonathan.
I don't know Buck Woody personally so I can't speak for him. While I agree that "the best" frequently depends on cirucumstances, it should never include code that is intentionally written to be slow. Writing any form of RBAR other than certain control-of-flow code is intentionally written to be slow. The tired old saw of not having enough training or knowledge simply isn't acceptable. If folks know that they'll be writing SQL, they should spend some time learning it even if it means learning it on their own time because their job depends on their knowledge. Equipped with such knowledge, folkks won't have to do 8 different tests... you'll already know the right way to do it which will also save on time and resources both in the short run and the long run.
For those folks that balk at the idea of spending time learning something about their livelihood on their own time... prepare to be left behind (ie. Unemployed) by the folks that don't balk.
We get it, you hate non-set-based programming. But sometimes an exercise has to consist of more than one SQL statement. And while only in unusual circumstances should an operation be deliberately slow (I think I found in the past on 2000 that a script that restores a database in one statement and starts reading or writing in it in the next statement is unsafe), there isn't necessarily a payback for a program being faster than "fast enough". If you can improve performance but at the risk of creating programmed errors or just burning up development time, when you have a prototype program that does the job clumsily but adequately and reliably, stop there. You can probably find something else useful to do. Yes, even if that first draft program is RBAR.
As for spending personal time developing workplace technical skills, you can get burned when an employer drops the product that you skilled up on. I have, more than once. I wonder if you ever heard of a database product called Recital. If you did, I wonder if you heard of Recital Internet Developer. Try selling that expertise in the twenty-first century. Then our outfit had the bright idea of marrying Java and SQL Server, products whose owners were in the middle of a decade of sueing each other. But I did get paid professional training on SQL Server 7, a thousand bucks per course. Then I was working full time on Recital again for two years, and, come to think, we never implemented SQL Server 7 either. I hate the fact I spent any personal time on this. We should band together and tell employers: we do this for pay, not because we enjoy it, and that includes learning about this junk. If you want knowledgeable employees, get them enknowledged on your dollar, not as their gift to you. No one owes anyone anything any more, and that goes both ways.
September 11, 2009 at 6:52 am
Jeff Moden (9/9/2009)
Actually, we've gotten a bit off track. I don't mind people asking questions on forums... in fact, I recommend it because there are so many great folks out there who love to share their knowledge and experience.But, to continue the metaphor...
When you're writing SQL (or any other programming language), you're not asking the plumber for advice on the heating system. Rather, you're taking the place of the plumber. If you don't know how to sweat pipes nor prepare the pipe joints for sweating and you have no intention of taking the time to do it right, then you shouldn't be doing the work. If you do, you'll either end up with leaky pipes or a cold solder joint that will blow apart unexpectedly when the pressure on the system changes. If you use aggressive acid flux (RBAR) instead of the more benign version recommended for such pipes just because you don’t have the time to find the correct flux (Set Based), then you'll run into similar problems.
I’m not suggesting that everyone who needs to sweat a pipe needs to take the time to become an absolute Master Plumber, but they should at least know enough to keep from causing damage whether that damage happen immediately or sometime down the road.
I think SQL Server Central is substantially for people who wear a DBA hat part of the time (click on "e-store" to get yours), but developers are outnumbered by application programmers, and the programmer's skill set doesn't have to include doing the DBA's job. Technical knowledge about SQL Server versus a computer-science school understanding of relational databases can be used to get better service from the server, but in my opinion, fundamentally a developer who writes a query that gets the correct results has carried their end of the deal. Making it efficient is a matter of database design and of SQL Server itself, and it isn't for a programmer to make up for inadequacies there. The programmer is more like a hairdresser; they have an interface to use the plumbing but they aren't responsible for it.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply