Are the posted questions getting worse?

  • Michael Earl (1/24/2009)


    I am a big believer in "Le mieux est l'ennemi du bien" - for many one-time, small-record count operations I often use RBAR solutions just to get things done right away.

    My only problem with that is that "many one-time, small-record count operations" get used by people with much larger needs and writing something that isn't RBAR doesn't take any longer.

    --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.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Jeff Moden (1/24/2009)


    Michael Earl (1/24/2009)


    I am a big believer in "Le mieux est l'ennemi du bien" - for many one-time, small-record count operations I often use RBAR solutions just to get things done right away.

    My only problem with that is that "many one-time, small-record count operations" get used by people with much larger needs and writing something that isn't RBAR doesn't take any longer.

    Yeah, Jeff logically sliced through my, "It's good enough for what you're doing argument," on one of these threads a while back. Bottom line is that the set-based code was faster to write and almost every time you can see that with as simple a measure as number of keystrokes. The counter-argument falls back to, "I know this other way better." But that argument gets squashed with the one about doing things right the first time (if we want others to do the right thing the first time, then we should hold ourselves to the same standard).

    K. Brian Kelley
    @kbriankelley

  • Brian, that's absolutely awesome. I couldn't have said it better myself. Thank you. And thanks for putting up with me on that post "a while back". You were a good sport about it.

    --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.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • RBarryYoung (1/24/2009)


    Heh. You know, I always have to follow these links to make sure that you aren't talking about me. Thank goodness too, I prefer my pork chops a plateful at a time!

    Seriously though, his heart seems to be in the right place wrt to "RBAR". I think that a little gentle correction from the guy who coined the term would probably fix his misunderstandings. 🙂

    Actually, my bark is worse than my bite... I lobbed the pork chop on that one. 😉

    Having your heart in the right place and actually doing the right thing are two different things, though. I couldn't believe my eyes when he was strutting all the anti-RBAR stuff and had just gotten done posting a while loop solution.

    --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.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Jeff Moden (1/24/2009)


    A perfect example can be found at the following link..

    http://qa.sqlservercentral.com/Forums/Topic642789-338-1.aspx#bm642945

    🙂 I'm busy witting a correction to one of his posts now. "Correlated subquery, inner query is executed once for each row from the outer table and this can be expensive on large datasets." (a normal, equality match, non top..order by subquery)

    http://qa.sqlservercentral.com/Forums/Topic642777-361-1.aspx

    He's trying, but I wish he'd verify his statements before posting....

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (1/25/2009)


    Jeff Moden (1/24/2009)


    A perfect example can be found at the following link..

    http://qa.sqlservercentral.com/Forums/Topic642789-338-1.aspx#bm642945

    🙂 I'm busy witting a correction to one of his posts now. "Correlated subquery, inner query is executed once for each row from the outer table and this can be expensive on large datasets." (a normal, equality match, non top..order by subquery)

    http://qa.sqlservercentral.com/Forums/Topic642777-361-1.aspx

    He's trying, but I wish he'd verify his statements before posting....

    You know, bad advice is a problem here, but it is hard to blame the posters completely for this. I just read in a technical blog/newsletter from one of the two most prominent SQL Users Groups (not PASS, the other one) this same statement, almost word for word!

    Now of course posters should check the facts before repeating them, but let me just add that this newsletter, a highly respected technical source, did have an example to "prove" it.

    And, yes, I agree "one example does not a sweeping generalization make", but I tend to feel that the problem is just as much "Experts" who either do not re-validate their "facts" for new releases and different conditions, or who just make sweeping generalizations from limited evidence, as it is the people who trust them.

    [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]

  • I'm not sure its "bad" advice in that lots of folks do get this information from the internet but never test it. Shoot, I'm in the process of fixing some of my own "bad" advice in one of my article and, yes... it too had proof in the form of code.

    Some of these "myths" didn't used to be myths... they were actual problems. Remember the big thing on SELECT/INTO supposedly locking up TempDB and all sorts of systems objects? That was actually repaired as part of 6.5 sp1 as a switch setting and was implemented into 7.0 without the switch setting.

    Here's another one... Right now, we all believe that CTE's "compile" more than once if used more than once (except on Tuesdays :D). If they fix that, the myth will travel on for years after that.

    I guess I'm saying that it's not always "bad" advice in that, at some time, it was good advice and did have tests that proved it. Things change.

    --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.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • True. I believe (from what I've been told) that correlated subqueries did always run once per row of the outer query, back in SQL 6.5.

    RBarryYoung (1/25/2009)


    You know, bad advice is a problem here, but it is hard to blame the posters completely for this.

    This doesn't really fall into my 'bad advice' category. It's an incorrect generalisation, sure, but it's not harmful. The bad advice that I posted a blog rant about is more the kind of advice that could damage the database or server if followed, and for that there isn't really a good excuse.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Personally I dislike labeling things bad and good, especially with code since it's a question of where and when things make sense.

    As I get older, I see less black and white, and more gray all the time. More "it depends" than "that is right or wrong"

  • jmohan_it (12/23/2008)

    --------------------------------------------------------------------------------

    Any one can tell. what ia a breakpoint in ssis? How is it setup? How do you disable?

    Have you looked through Books Online, specifically the sections on SSIS?

    --------------------------------------------------------------------------------

    Gail Shaw

    Gail saves the day.

    I read through the above thread and many others just wanting to say "Read a book, Google and read the results and especially read Books Online"

    Some posters seem to be so arrogant that they will not even deign to actually READ anything! With that attitude why are they even working when they expect others to do their work for them?

    I also get hot under the collar about bad spelling and grammar - I had a traditional English grammar school education (in the times when we had a proper education system) and spelling and grammatical mistakes stand out a mile! They spoil my concentration and distract from the message the author intended to convey.

    In todays headline article for example we are asked to "Invision yourself". Even my dictionary doesn't have this word. ENVISAGE yourself however is acceptable.

    The same article has the convoluted phrase

    This wil be you taking out two birds with one stone by you getting direct information of the documentable assignments

    .

    UGH!

    But thank you for the space to vent my feelings and to the "Senior" posters of this site for their answers to serious sensible questions that have helped more than just the poster.

  • Jeff, something I have to ask:

    You keep mentioning that recursive CTEs are worse than cursors. I can see that in some cases, but in cases like a hierarchy crawl, I've seen cursor solutions to that, and they were much, much worse than CTEs.

    Do you have something specific in mind when you say they're worse, or do you have some data that shows they're better on actually recursive solutions?

    The places where I've seen recursive CTEs perform poorly have been places where recursion wasn't actually needed at all.

    - 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

  • Steve Jones - Editor (1/25/2009)


    Personally I dislike labeling things bad and good, especially with code since it's a question of where and when things make sense.

    As I get older, I see less black and white, and more gray all the time. More "it depends" than "that is right or wrong"

    I'd say I think you are right, but I'm not sure if that contradicts your statement.

    My head hurts.

  • Steve Jones - Editor (1/25/2009)


    Personally I dislike labeling things bad and good, especially with code since it's a question of where and when things make sense.

    If you've read my blog rant, you know what I'm referring to when I mention bad advice - suggestions so wrong they'll damage the database or server if followed.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Good or bad, as long as stuff isn't plagiarized.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • P Jones (1/26/2009)


    I also get hot under the collar about bad spelling and grammar - I had a traditional English grammar school education

    Just bear in mind that not everyone posting here has English as a first language, or even maybe as a second language. How good's your Spanish spelling and grammar? (as an example)

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 15 posts - 916 through 930 (of 66,000 total)

You must be logged in to reply to this topic. Login to reply