April 17, 2009 at 3:28 pm
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
Lynn Pettis (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
I absolutely agree, but I did not say training was a luxury. I said ...well you can read what I said. 🙂
What I'm saying is that while the training is going on I still have product to deliver. So I deliver the best solution I can today which is when it's due.
Fortunately formal in-the-classroom training for large blocks of time is not the only type of training you can perform. On-the-job training is particularly important. When people are under pressure they take shortcuts that will cost you in the long run. Training allows people to write higher quality code in a shorter amount of time.
Tomorrow I find out about some new whiz bang feature in training... great I'll use that on the next project, but yesterday's project with the old "not right" solution, that works fine by the way, is out the door. If I have the luxury of some fee time maybe I'll be able to refactor it!
Or, depending on how your process works, you may have been told about this whiz bang new feature earlier during an architectural review. Or you may learn about this whiz bang new feature during a code review. Or you may learn about this whiz bang new feature from a senior mentor. And btw, set-based programming is not exactly a "whiz bang new feature".
Yep, all of those things "can" happen, but sometimes they don't. If they do and you can use it in your current project great!
The "whiz bang new feature" can be anything, I'm not singling out set-based programming, but it might be if you just found out about it. The point is it's "whiz bang" to you even if it's been there for years. Because you did not know about it doesn't make you a bad developer especially if you are new to the environment.
The fact that the project "works fine by the way" is often a very narrow definition of the word "fine". What is more often than not meant is "it works fine by the way. On the system we tested it on here by the way. With the amount of data we tested it with by the way. Under the stress tests that we subjected it to by the way." Particularly when you're talking about cursors you can expect significant performance degradation under a variety of conditions. When a table triples in size, for instance. At least in the field I work in it's not a good idea to bet the farm on the amount of data in tables shrinking or remaining the same over time.
Hmm, my definition of "works fine" is it meets the requirements as put forth in the specification now and into the future. Are you saying your specs don't contain "acceptable performance under load" criteria? And as I stated earlier, I agree cursors should be your last choice in a solution due to performance issues, but maybe a cursor will work just fine for a given solution. As I said, to me cursors aren't good or bad, just another tool in the toolbox. Granted a little used tool:-)
April 17, 2009 at 3:30 pm
[font="Tahoma"]It may be a fact that you did not know what you were doing, or you were using a previous version of software, or that you didn't have proper training. It may be true that you implemented RBAR solutions that haven't bitten you in the hiney yet. Maybe there are no complaints. But backing up this practice by saying it's not necessary to do things in a more efficient and concise way is just silly. Of course you can write crappy code. But if someone is telling you a better way, why waste time defending the cursor? Once upon a time, my job WAS writing cursors so that COBOL could operate on DB2 tables. Why? Because the COBOL programmers thought cursors were not intuitive. Let the analyst write them, that's not real code. Let me tell you, there were times I felt pretty dang whiz-bang clever about my cursors! But it's a different century and technology has grown, SQL Server has advanced to the point that they are rarely if ever needed. HOORAY!!!!!!
Now, it's Friday afternoon, it's been raining all day and I am going home to pack for an all-day out-door mud- and Blues- fest tomorrow in Athens, TX :hehe:[/font]
😎 Kate The Great :w00t:
If you don't have time to do it right the first time, where will you find time to do it again?
April 17, 2009 at 4:02 pm
The irony here, of course, is that the thing that some readers found most objectionable was that I said that sometimes developers don't care about the quality of their code...
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
April 17, 2009 at 4:51 pm
bruce.trimpop (4/17/2009)
Hmm, my definition of "works fine" is it meets the requirements as put forth in the specification now and into the future. Are you saying your specs don't contain "acceptable performance under load" criteria? And as I stated earlier, I agree cursors should be your last choice in a solution due to performance issues, but maybe a cursor will work just fine for a given solution. As I said, to me cursors aren't good or bad, just another tool in the toolbox. Granted a little used tool:-)
Well, that was a long and tortuous road back to where we started, assuming we started with Bruce's comment supporting the idea that the simplicity (and by implication, the ease of use) for a technique is largely determined by the context of the developer's experience and skill-set.
If you know cursors and procedural development then cursors are easier than set based. If you know set based and not cursors then set based is easier. If you know both then neither is harder than the other. It becomes a matter of which is best to use for a particular situation. I think it simply boils down to, cursors tend not to be the best choice because SQL Server is more optimized for a "Set Based" approach. I don't see that as making cursors "bad", just not your first choice if you understand set based development in a SQL environment.
By itself, it's really not something to argue with, now is it? The only argument now would be how often "little used" would be, or whether developers have an obligation to, as Bruce says, "... understand set based development in a SQL environment."
And that's a key point in this discussion. There's rarely any reason not to move a shop's standard methodology forward through training, whether formal or informal. Then, the idea is once you know how to use set-based methods, you'll use them for all your work, large or small. Get used to that power drill, whether you're building a birdhouse or an office building, and you won't go back to a brace and bit again, even for the smallest job (had to use an woodworking analogy in memory of my dad, a carpenter).
To be fair, I think Bruce may be sorry he used the word "luxury" in that post. I have empathy for him on that. I've been in the position (a number of years ago) of having management say "we can't afford to send you to class -- just go get a book for $50 and read it", or "no, we're not buying the MS SDK for OS/2. Borrow a manual." So, you make do with what you've got. But, as has been pointed out, even if your management won't pay for training, you have to manage your own career responsibly and that means staying current with tools and techniques.
April 17, 2009 at 4:56 pm
bruce.trimpop (4/17/2009)
GSquared (4/17/2009)
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
It truly amazes me how some peoples worlds are black and white. I'd love to live it that world. First, I was NOT defending the practice I was stating that some companies in the real world whether right or wrong do not have the luxury or time to do things "right" by your definition. They have obligations (contractual or otherwise) to get it done and have it work under given time constraints.
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab"
Ok how about this if you want to talk about medicine, a medic on the battle field can stop the bleeding and sow up a wound with 10 stitches but that patient will live and he can move on to the next patient, or he can take his time, "do it right!" and use 50 stitches while the next patient bled to death.
In my world I often don't have time to do a perfect solution, I have to do the best I can under the time/contractual obligations that I am presented with and get something that works to the customer. Could it be done better...given more time absolutely....does work the way it was delivered...you betcha!
Here's the issue with the medic analogy, the medic keeps him from dying, but then a better trained and much more expensive doctor fixes it right. In the software development world the medic is the in-house programmer who "gets the job done on time" and the doctor is $200+/hour consultant who comes in and does the performance tuning because the medic's code wasn't the real fix. Sure this is acceptable to your company when you are a Software company and you send out the under-performing product and get to send out the high-paid consultant to work with your customer to get your poorly performing database to perform better. This is why we pay 18-20% maintenance on packaged software, they don't do it right the first time, so we pay so they can eventually fix it.
Man, I was really trying to stay out this discussion, but I got ticked off at the end of the day at the office so I don't mind being a bit snippy here either.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 17, 2009 at 5:06 pm
Jack Corbett (4/17/2009)
bruce.trimpop (4/17/2009)
GSquared (4/17/2009)
I can't imagine a single other professional field where people would actually defend the practice of "we don't do it right, because we can't be bothered to learn how".
It truly amazes me how some peoples worlds are black and white. I'd love to live it that world. First, I was NOT defending the practice I was stating that some companies in the real world whether right or wrong do not have the luxury or time to do things "right" by your definition. They have obligations (contractual or otherwise) to get it done and have it work under given time constraints.
Imagine how you would feel if your physician told you that he uses bloodletting instead of antibiotics, because antibiotics are complex, and bloodletting is "something that my nurses are already pretty much trained to do, because they know how to take samples for the lab"
Ok how about this if you want to talk about medicine, a medic on the battle field can stop the bleeding and sow up a wound with 10 stitches but that patient will live and he can move on to the next patient, or he can take his time, "do it right!" and use 50 stitches while the next patient bled to death.
In my world I often don't have time to do a perfect solution, I have to do the best I can under the time/contractual obligations that I am presented with and get something that works to the customer. Could it be done better...given more time absolutely....does work the way it was delivered...you betcha!
Here's the issue with the medic analogy, the medic keeps him from dying, but then a better trained and much more expensive doctor fixes it right. In the software development world the medic is the in-house programmer who "gets the job done on time" and the doctor is $200+/hour consultant who comes in and does the performance tuning because the medic's code wasn't the real fix. Sure this is acceptable to your company when you are a Software company and you send out the under-performing product and get to send out the high-paid consultant to work with your customer to get your poorly performing database to perform better. This is why we pay 18-20% maintenance on packaged software, they don't do it right the first time, so we pay so they can eventually fix it.
Man, I was really trying to stay out this discussion, but I got ticked off at the end of the day at the office so I don't mind being a bit snippy here either.
Sounds like you could have used the SNOW DAY. I was dressed and my tie half tied when I got the call this morning. It has been a wonderful day off.
April 17, 2009 at 5:20 pm
Lynn Pettis (4/17/2009)
Sounds like you could have used the SNOW DAY. I was dressed and my tie half tied when I got the call this morning. It has been a wonderful day off.
Could have used the day off, but not the SNOW. Lived with that for 37+ years and finally moved to Florida so I don't have to deal with anymore. I don't ever want to go back.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 17, 2009 at 6:17 pm
Jack Corbett (4/17/2009)
Lynn Pettis (4/17/2009)
Sounds like you could have used the SNOW DAY. I was dressed and my tie half tied when I got the call this morning. It has been a wonderful day off.Could have used the day off, but not the SNOW. Lived with that for 37+ years and finally moved to Florida so I don't have to deal with anymore. I don't ever want to go back.
That's what's nice about living in Colorado at the foot of the Rockies. The snow doesn't stay around long down here, but it sure makes the mountains pretty!
April 17, 2009 at 8:07 pm
bruce.trimpop (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
Lynn Pettis (4/17/2009)
Mike C (4/17/2009)
bruce.trimpop (4/17/2009)
john.arnott (4/17/2009)
Stephen Hirsch (4/17/2009)
. . .cursors tend to be easier to write . . .I think you'll get some argument on this. Cursors are easier to understand for someone coming from a procedural programming background -- like that C++ programmer Mike C tells us about in his last post. But one of the main points that I think RBarry is making in his article is that once a developer understands the mind-set of declarative programming and set-based solutions, they are often actually easier to understand.
Both arguments are relative to the developer's experience....
I think the question then becomes whether you allow a developer who's lacking in experience to lower your expectations as an organization, or do you raise the skill levels of your inexperienced developers and teach them the best way to accomplish the tasks at hand to maintain high standards and meet high expectations?
Training is a luxury??? I'm sorry, it mandatory. If the company can't/won't provide it, then developers need to expend their own time and money in learning how to do their job better. It is part of their own professional development, keeping themselves relevant in the ever changing IT field.
I absolutely agree, but I did not say training was a luxury. I said ...well you can read what I said. 🙂
What I'm saying is that while the training is going on I still have product to deliver. So I deliver the best solution I can today which is when it's due.
Fortunately formal in-the-classroom training for large blocks of time is not the only type of training you can perform. On-the-job training is particularly important. When people are under pressure they take shortcuts that will cost you in the long run. Training allows people to write higher quality code in a shorter amount of time.
Tomorrow I find out about some new whiz bang feature in training... great I'll use that on the next project, but yesterday's project with the old "not right" solution, that works fine by the way, is out the door. If I have the luxury of some fee time maybe I'll be able to refactor it!
Or, depending on how your process works, you may have been told about this whiz bang new feature earlier during an architectural review. Or you may learn about this whiz bang new feature during a code review. Or you may learn about this whiz bang new feature from a senior mentor. And btw, set-based programming is not exactly a "whiz bang new feature".
Yep, all of those things "can" happen, but sometimes they don't. If they do and you can use it in your current project great!
The "whiz bang new feature" can be anything, I'm not singling out set-based programming, but it might be if you just found out about it. The point is it's "whiz bang" to you even if it's been there for years. Because you did not know about it doesn't make you a bad developer especially if you are new to the environment.
The fact that the project "works fine by the way" is often a very narrow definition of the word "fine". What is more often than not meant is "it works fine by the way. On the system we tested it on here by the way. With the amount of data we tested it with by the way. Under the stress tests that we subjected it to by the way." Particularly when you're talking about cursors you can expect significant performance degradation under a variety of conditions. When a table triples in size, for instance. At least in the field I work in it's not a good idea to bet the farm on the amount of data in tables shrinking or remaining the same over time.
Hmm, my definition of "works fine" is it meets the requirements as put forth in the specification now and into the future. Are you saying your specs don't contain "acceptable performance under load" criteria?
But of course... without acceptable performance criteria you can't really draft up an SLA for an application 🙂 However, things often change -- often beyond your control -- and what happens when the load which was initially spec'd out at 100 users and 100 GB of data suddenly jumps to 300 users and 500 GB of data? Not that this is a bad thing; it just means more people have confidence in your database or app. and feel they can get value from it. The question is does your database and application scale or is it strictly guaranteed to "work fine" only at the low end of the scale? Can you easily tune it in the future or do you have to completely refactor the entire app. to undo all the stuff that "worked fine" initially?
Many of the "whiz bang new features" should be brought to your attention well before completion of the project during the technical spec writing process, and the regular code reviews and architectural reviews that I'm sure are scheduled as part of your normal development process, right? 🙂
April 17, 2009 at 8:13 pm
RBarryYoung (4/17/2009)
The irony here, of course, is that the thing that some readers found most objectionable was that I said that sometimes developers don't care about the quality of their code...
The arguments I hear around these parts seem to back up your assertion. What I've read seems to reinforce that time-to-market and developing down for the lowest common denominator are more important than quality for some.
April 17, 2009 at 8:21 pm
Jack Corbett (4/17/2009)
Here's the issue with the medic analogy, the medic keeps him from dying, but then a better trained and much more expensive doctor fixes it right. In the software development world the medic is the in-house programmer who "gets the job done on time" and the doctor is $200+/hour consultant who comes in and does the performance tuning because the medic's code wasn't the real fix.
It's almost scary how many billable hours I've spent fixing poorly constructed databases and code. I spent nearly 3 solid years consulting doing nothing but fixing low-quality code and poorly constructed databases. Oh the horrors I've seen... and fixed 🙂
April 17, 2009 at 9:38 pm
Mike C (4/17/2009)
RBarryYoung (4/17/2009)
The irony here, of course, is that the thing that some readers found most objectionable was that I said that sometimes developers don't care about the quality of their code...The arguments I hear around these parts seem to back up your assertion. What I've read seems to reinforce that time-to-market and developing down for the lowest common denominator are more important than quality for some.
Well stated on both parts and I absolutely agree. I'm amazed at some of the objections. If someone spent as much time studying and practicing the correct ways as they have arguing on this thread in favor of performance challenged code because they think it's easier, faster to write, and somehow more intuitive, there would be no need for either this thread or the related article.
--Jeff Moden
April 18, 2009 at 11:15 am
I agree with that and with what Joe said. That's why I think article's like Barry's series are so important.
--Jeff Moden
April 18, 2009 at 5:47 pm
Bruce W Cassidy (4/16/2009)
WayneS (4/16/2009)
Thomas (4/15/2009)
Using a cross join is not itself counter-intuitive. Using it in this fashion to generate a bunch of numbers probably is to most developers.I think that this is one of the points that Jeff was making. Developers need to learn how to do set-based operations, so that when they see one it will be intuitive.
The whole point of SQL is to work with sets. Developers need to learn that. Complaining that it is "too complex" seems a bit counter-intuitive to me: isn't the point to learn the language? CROSS JOINs and TOP operators aren't particularly complex parts of SQL either.
So for a developer who finds the set-based method "arcane", I'd regard that as an indication that they need to spend more time learning SQL.
I just thought of something that I wish I had included with my original post.
Programming languages have evolved. 15 years ago, you had plain old programming languages, complete with procedural ways of doing things. Then came object-oriented programming languages. To be a good OOP programmer, one had to start thinking of things as objects, and you had to deal with OOP principals, such as events, properties, encapusaltion and polymorphism. This thought shift did not occur overnight - you had to immerse yourself in it and work at it. Not all programmers could make this shift, and for others it took a long time before the light clicked on behind their eyes and they understood it.
Well, SQL is set-based. Once again, you need to immerse yourself into the way that the tool you have chosen (or been directed) to use works the most effectively. It's not easy, but the rewards are worth it.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 19, 2009 at 1:59 pm
[font="Verdana"]The quotes got a bit hairy, so I'm just going to reply with some points.
Firstly, there are two Bruce's in this conversation! Eeek! :w00t:
Secondly, comparing the use of TOP and CROSS JOIN with anonymous members is a bit... er, apples and oranges. The point I was trying to make is that neither TOP nor CROSS JOIN are particularly complex parts of the SQL language, and asking developers to learn them really isn't asking too much. Whereas anonymous members still give me headaches!
Thirdly, while I do use row-by-row methods occasionally, I never use a cursor. I find the syntax too arcane. Seriously!
[/font]
Viewing 15 posts - 271 through 285 (of 380 total)
You must be logged in to reply to this topic. Login to reply