Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««4,0644,0654,0664,0674,068»»»

Are the posted questions getting worse? Expand / Collapse
Author
Message
Posted Monday, July 22, 2013 2:50 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 3:34 PM
Points: 8,295, Visits: 8,748
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article???

Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.


Tom
Post #1476279
Posted Monday, July 22, 2013 6:35 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 5:42 PM
Points: 3,596, Visits: 5,112
L' Eomot Inversé (7/22/2013)
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article???

Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.


Tom and Brandie - For the record I'm not upset by your posts. Circumstances have helped me to develop a pretty thick skin over the years. And what I said to Brandie about the author being an amateur is quite true. I most certainly consider myself so.

In the article's defense (without meaning to sound defensive), I attempted to write it from the perspective of someone that is new to MERGE. Surely there are a few of those folks out there, along with many others that use it sufficiently to be aware of all of the wrinkles of it when you do.

The flow of the article was also attempting to mimic the situation where requirements evolve, either because the users change their minds or because anomalies in the data require a bit of adaptation. Perhaps I was mistaken to think that ever happens.

Your comments will be taken into consideration when I write in the future, but I should say that I write for fun. Occasionally, if someone cares to read it and gain from it, that is a bonus. Since I am no SQL-guru, I believe there is a place for those that have something to offer to beginners, mainly because they are not far removed from that state. Many of the highly technical articles I've read are way beyond what a beginner would derive a lot of value from. I try to cater to a lower common denominator.



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1476319
Posted Monday, July 22, 2013 7:14 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 12:37 AM
Points: 1,661, Visits: 5,225
dwain.c (7/22/2013)
L' Eomot Inversé (7/22/2013)
Sean Lange (7/22/2013)
Gosh Tom, how do you really feel about that article???

Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.


Tom and Brandie - For the record I'm not upset by your posts. Circumstances have helped me to develop a pretty thick skin over the years. And what I said to Brandie about the author being an amateur is quite true. I most certainly consider myself so.

In the article's defense (without meaning to sound defensive), I attempted to write it from the perspective of someone that is new to MERGE. Surely there are a few of those folks out there, along with many others that use it sufficiently to be aware of all of the wrinkles of it when you do.

The flow of the article was also attempting to mimic the situation where requirements evolve, either because the users change their minds or because anomalies in the data require a bit of adaptation. Perhaps I was mistaken to think that ever happens.

Your comments will be taken into consideration when I write in the future, but I should say that I write for fun. Occasionally, if someone cares to read it and gain from it, that is a bonus. Since I am no SQL-guru, I believe there is a place for those that have something to offer to beginners, mainly because they are not far removed from that state. Many of the highly technical articles I've read are way beyond what a beginner would derive a lot of value from. I try to cater to a lower common denominator.


Dwain, I guess it comes down to whether the reader thought you were writing in the first person from an "expert's" position or, as I did, that you were conveying a novice's story that unfolds as you read...

For me, I read it exactly as you describe here, a kind of timeline of someone's exploration of the command and how it can bite you if you don't fully comprehend the way it works.

In that context, it made sense to me, and also described pretty much the way my first attempt at using Merge worked out - unintentionally deleting rows due to poor scoping. (I also always test inside a transaction for precisely this reason - that should be a SQL Spackle in it's own right).

So, all in all, I don't think it deserves the criticism - I say blame the reader


MM


  • MMGrid Addin
  • MMNose Addin


  • Forum Etiquette: How to post Reporting Services problems
  • Forum Etiquette: How to post data/code on a forum to get the best help - by Jeff Moden
  • How to Post Performance Problems - by Gail Shaw

  • Post #1476322
    Posted Tuesday, July 23, 2013 1:08 AM


    SSCertifiable

    SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

    Group: General Forum Members
    Last Login: Yesterday @ 9:40 AM
    Points: 6,777, Visits: 12,883
    L' Eomot Inversé (7/22/2013)
    dwain.c (7/17/2013)
    Brandie Tarvin (7/17/2013)
    WHOO HOO!

    Not only did I just teach myself how to use MERGE (never had time or reason), but I managed to use it correctly with a Cross Applied Tally table and an INNER JOIN inside the USING clause.

    <SnoopyDance>

    And it only took me 30 minutes to figure it all out.


    One thing to take care with when using MERGE though: A Hazard of Using the SQL Merge Statement

    It's not a bug it's a feature, but does have the potential to cause you grief if you don't know about it.

    That reference is one of the most stupid pieces of nonsense I've ever seen. First the guy says he wants to merge his source into his target. Then he produces a chunk of code which does something like that. But the result of that is not what was required, because it's failed to delete a row that was in the target but not matched in the source - in other words, because it failed to violate his stated requirement in a particular way in which he wants his stated requirement violated. He then produces a piece of utterly silly code which just destroys his target and substitutes the source - and we are supposed to be surprised that that doesn't work. Then he produces, finally, his code which is the answer to the problem - but it doesn't meet his stated requirement, because it does indeed achieve the violation of that requirement that he introduced earlier to do job which he apparently wants, instead of the requirement that was actually fulfilled by the first piece of code he rejected. I just hope that I never have to deal with a developer or a DBA who leant from that guy!


    Bad hair day, Tom?


    “Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
    Exploring Recursive CTEs by Example Dwain Camps
    Post #1476371
    Posted Tuesday, July 23, 2013 1:43 AM


    SSCertifiable

    SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

    Group: General Forum Members
    Last Login: Yesterday @ 9:40 AM
    Points: 6,777, Visits: 12,883
    mister.magoo (7/22/2013)
    dwain.c (7/22/2013)
    L' Eomot Inversé (7/22/2013)
    Sean Lange (7/22/2013)
    Gosh Tom, how do you really feel about that article???

    Just as described, but if I'd realised who wrote it I would have made the comment privately, not here.


    Tom and Brandie - For the record I'm not upset by your posts. Circumstances have helped me to develop a pretty thick skin over the years. And what I said to Brandie about the author being an amateur is quite true. I most certainly consider myself so.

    In the article's defense (without meaning to sound defensive), I attempted to write it from the perspective of someone that is new to MERGE. Surely there are a few of those folks out there, along with many others that use it sufficiently to be aware of all of the wrinkles of it when you do.

    The flow of the article was also attempting to mimic the situation where requirements evolve, either because the users change their minds or because anomalies in the data require a bit of adaptation. Perhaps I was mistaken to think that ever happens.

    Your comments will be taken into consideration when I write in the future, but I should say that I write for fun. Occasionally, if someone cares to read it and gain from it, that is a bonus. Since I am no SQL-guru, I believe there is a place for those that have something to offer to beginners, mainly because they are not far removed from that state. Many of the highly technical articles I've read are way beyond what a beginner would derive a lot of value from. I try to cater to a lower common denominator.


    Dwain, I guess it comes down to whether the reader thought you were writing in the first person from an "expert's" position or, as I did, that you were conveying a novice's story that unfolds as you read...

    For me, I read it exactly as you describe here, a kind of timeline of someone's exploration of the command and how it can bite you if you don't fully comprehend the way it works.

    In that context, it made sense to me, and also described pretty much the way my first attempt at using Merge worked out - unintentionally deleting rows due to poor scoping. (I also always test inside a transaction for precisely this reason - that should be a SQL Spackle in it's own right).

    So, all in all, I don't think it deserves the criticism - I say blame the reader


    Any article which offers this much encouragement to the reader to explore and test - and shows them how to do it - deserves a little praise, surely? I'm not exactly the sharpest knife in the block but the target audience and the author's intent are as clear to me as they are to MM, and in that context I'd argue that the article works very well. More like this please, Dwain.


    “Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
    Exploring Recursive CTEs by Example Dwain Camps
    Post #1476393
    Posted Tuesday, July 23, 2013 4:32 AM


    SSCertifiable

    SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

    Group: General Forum Members
    Last Login: Yesterday @ 11:56 AM
    Points: 7,073, Visits: 6,231
    As a writer and editor (outside of SQL Server), I believe it's incumbent upon the author to set reader expectations at the outset. That being said, if an article is for beginners and about another beginner's issues, that should be stated in the first paragraph (even the first sentence) so that people read it in the mindset that it was written. Otherwise there is the assumption of expertise from just reading the title.

    When reader expectations are set, they are much less likely to fuss about the article (or book) in question unless the article / book flies against those expectations. It allows for a proper discussion based on the level of the article.


    Brandie Tarvin, MCITP Database Administrator

    Webpage: http://www.BrandieTarvin.net
    LiveJournal Blog: http://brandietarvin.livejournal.com/
    On LinkedIn!, Google+, and Twitter.

    Freelance Writer: Shadowrun
    Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
    Post #1476475
    Posted Tuesday, July 23, 2013 6:49 AM


    Hall of Fame

    Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

    Group: General Forum Members
    Last Login: Yesterday @ 5:42 PM
    Points: 3,596, Visits: 5,112
    Brandie Tarvin (7/23/2013)
    As a writer and editor (outside of SQL Server), I believe it's incumbent upon the author to set reader expectations at the outset. That being said, if an article is for beginners and about another beginner's issues, that should be stated in the first paragraph (even the first sentence) so that people read it in the mindset that it was written. Otherwise there is the assumption of expertise from just reading the title.

    When reader expectations are set, they are much less likely to fuss about the article (or book) in question unless the article / book flies against those expectations. It allows for a proper discussion based on the level of the article.


    Brandie, I have to say +1 for standing your ground. Expectations setting is always a good thing, but I should point out that it borders on psychology. As I am no psychologist, I'd have to speculate that it must be done carefully. Let's try to understand why.

    1. There is a concept called (and forgive me for making this sound so formal) illusory superiority. You can Google that and see a wide body of research or simply Google "average people don't think they're average" to get a wider feel for the concept.

    2. If I were to ask you to rate your driving skill as below average, average or above average, how would you respond? I'm guessing 90% of the population of drivers would rate their skills as "above average," but statistically it is only possible that around 50% of drivers meet that criteria (please excuse me for playing fast and loose with mean vs. median).

    The gist of what I'm trying to say here is that if I say this article is "by a beginner and for beginners" at the start of it, then I'm likely to lose 50% of the audience that might benefit from it.

    Let's try a challenge for you. Most editors probably analyze the demographic of books and stories they publish to gauge the amount of money they'll make selling copies. The challenge is, in the preface of your next book you should say immediately "this book is targeted to a demographic of 25 to 40 year olds - if you're younger wait a few years to read it and if you're older forget it because you'll never get it." OK, let's make it easier, forget that last part. Are you going to turn away immediately part of the non-targeted demographic and risk sales?

    And there probably were cases (as ChrisM pointed out) where some non-beginners might have learned something (http://www.sqlservercentral.com/Forums/FindPost1438429.aspx).

    Again I do want to emphasize that I am not trying to be defensive, rather what I'm trying to say is that there is somewhat of a method to my (amateur) madness. I'd venture to say that 90% of the people that attend this site are not SQL MVPs and it is highly possible that 15% or less actually have one or more MS SQL certs such as yourself. That puts you in some pretty good (and scarce) company. That's a demographic I don't even meet. So if all of the articles are targeted at that 15% and they say so in the beginning, how many people that might benefit get turned off and turned away?

    On the other hand, suppose you take a risk and don't set any expectations. An article is like a TV program. When you get bored you change the channel, or turn the page or press the back button on your browser. I'm not saying you shouldn't set expectations. What I'm saying is that it must be done carefully so as to not hurt your chances of improving someone's skill. And let's face it, I'd venture a guess that pretty much anybody in that top 15% I was talking about have probably faced people with a whole lot lower level of technical skill than they give themselves credit for.

    I hope people see this as an opportunity for intellectual discourse and not a rant. And let me add that I'm taking a rather extreme viewpoint here and I know it. Since this is psychology it is many shades of gray and not the black and white point of view I'm trying to portray.



    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
    Since random numbers are too important to be left to chance, let's generate some!
    Learn to understand recursive CTEs by example.
    Splitting strings based on patterns can be fast!
    Post #1476550
    Posted Tuesday, July 23, 2013 7:22 AM


    SSCertifiable

    SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

    Group: General Forum Members
    Last Login: Yesterday @ 11:56 AM
    Points: 7,073, Visits: 6,231
    dwain.c (7/23/2013)
    1. There is a concept called (and forgive me for making this sound so formal) illusory superiority.


    I don't know why you're making this reference in regards to what I said. I'm talking about what authors call "The promise to the reader" and was actually responding to recent posts by other Threadzians.

    Let me explain what the promise to the reader is. Say I tell you I'm writing an article on Doctor Who. And you happen to be a fan of the BBC science fiction series Doctor Who. But you click open the article and find out that I'm referencing a medical doctor and the actual discussion is about "the doctor who did this nasty thing to a patient."

    How would you feel?

    As the article writer, I broke my promise to the reader by making a grab for attention on keywords that I knew would make people jump and then not following through.

    Conversely, if I promise an article on SQL Server Internals to SSC, some people might assume I am talking from a position of expertise since SQL Server Internals are a complicated subject. But the truth is that I barely know enough to scratch the surface of this topic. So if I write such an article, the first thing I would tell people is "I'm new at this, but this is what I saw when I did X thing at my job." That way Gail, Tom, Jeff, and everyone else with more experience than me would (I hope) moderate their comments from "You are clueless" to more of a "Well, have you checked out this link that explains that behavior" or "You're misinterpreting your results."

    Not that any of them ever respond that way, but at least I'm setting the expectation at the start of the article so that people know where my POV is coming from. That's also why I would write my business case at the start. Giving the readers a starting point from which to view the code is more of a practical issue to me than it is any attempt at superiority.


    Brandie Tarvin, MCITP Database Administrator

    Webpage: http://www.BrandieTarvin.net
    LiveJournal Blog: http://brandietarvin.livejournal.com/
    On LinkedIn!, Google+, and Twitter.

    Freelance Writer: Shadowrun
    Latchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.
    Post #1476565
    Posted Tuesday, July 23, 2013 7:25 AM
    SSCrazy

    SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

    Group: General Forum Members
    Last Login: Thursday, April 10, 2014 9:10 AM
    Points: 2,694, Visits: 6,895
    dwain.c (7/23/2013)
    Brandie Tarvin (7/23/2013)
    As a writer and editor (outside of SQL Server), I believe it's incumbent upon the author to set reader expectations at the outset. That being said, if an article is for beginners and about another beginner's issues, that should be stated in the first paragraph (even the first sentence) so that people read it in the mindset that it was written. Otherwise there is the assumption of expertise from just reading the title.

    When reader expectations are set, they are much less likely to fuss about the article (or book) in question unless the article / book flies against those expectations. It allows for a proper discussion based on the level of the article.


    Brandie, I have to say +1 for standing your ground. Expectations setting is always a good thing, but I should point out that it borders on psychology. As I am no psychologist, I'd have to speculate that it must be done carefully. Let's try to understand why.

    1. There is a concept called (and forgive me for making this sound so formal) illusory superiority. You can Google that and see a wide body of research or simply Google "average people don't think they're average" to get a wider feel for the concept.

    2. If I were to ask you to rate your driving skill as below average, average or above average, how would you respond? I'm guessing 90% of the population of drivers would rate their skills as "above average," but statistically it is only possible that around 50% of drivers meet that criteria (please excuse me for playing fast and loose with mean vs. median).

    The gist of what I'm trying to say here is that if I say this article is "by a beginner and for beginners" at the start of it, then I'm likely to lose 50% of the audience that might benefit from it.

    Let's try a challenge for you. Most editors probably analyze the demographic of books and stories they publish to gauge the amount of money they'll make selling copies. The challenge is, in the preface of your next book you should say immediately "this book is targeted to a demographic of 25 to 40 year olds - if you're younger wait a few years to read it and if you're older forget it because you'll never get it." OK, let's make it easier, forget that last part. Are you going to turn away immediately part of the non-targeted demographic and risk sales?

    And there probably were cases (as ChrisM pointed out) where some non-beginners might have learned something (http://www.sqlservercentral.com/Forums/FindPost1438429.aspx).

    Again I do want to emphasize that I am not trying to be defensive, rather what I'm trying to say is that there is somewhat of a method to my (amateur) madness. I'd venture to say that 90% of the people that attend this site are not SQL MVPs and it is highly possible that 15% or less actually have one or more MS SQL certs such as yourself. That puts you in some pretty good (and scarce) company. That's a demographic I don't even meet. So if all of the articles are targeted at that 15% and they say so in the beginning, how many people that might benefit get turned off and turned away?

    On the other hand, suppose you take a risk and don't set any expectations. An article is like a TV program. When you get bored you change the channel, or turn the page or press the back button on your browser. I'm not saying you shouldn't set expectations. What I'm saying is that it must be done carefully so as to not hurt your chances of improving someone's skill. And let's face it, I'd venture a guess that pretty much anybody in that top 15% I was talking about have probably faced people with a whole lot lower level of technical skill than they give themselves credit for.

    I hope people see this as an opportunity for intellectual discourse and not a rant. And let me add that I'm taking a rather extreme viewpoint here and I know it. Since this is psychology it is many shades of gray and not the black and white point of view I'm trying to portray.


    When I write about tech, I tend to write up my process including discovery, wrong turns, mistakes, etc... I think and hope that the articles are clear that that's what I'm doing. As I'm writing from the perspective of someone who is figuring things out, I don't have to worry about falling short of perceptions as an "expert" and I can walk through things for beginners while still providing information for experts. I don't really know if it works, but I enjoy it.


    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams
    Post #1476567
    Posted Tuesday, July 23, 2013 7:40 AM


    Ten Centuries

    Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

    Group: General Forum Members
    Last Login: Monday, April 07, 2014 7:35 AM
    Points: 1,172, Visits: 2,413
    Brandie Tarvin (7/23/2013)
    dwain.c (7/23/2013)
    1. There is a concept called (and forgive me for making this sound so formal) illusory superiority.


    I don't know why you're making this reference in regards to what I said. I'm talking about what authors call "The promise to the reader" and was actually responding to recent posts by other Threadzians.

    Let me explain what the promise to the reader is. Say I tell you I'm writing an article on Doctor Who. And you happen to be a fan of the BBC science fiction series Doctor Who. But you click open the article and find out that I'm referencing a medical doctor and the actual discussion is about "the doctor who did this nasty thing to a patient."

    How would you feel?

    As the article writer, I broke my promise to the reader by making a grab for attention on keywords that I knew would make people jump and then not following through.

    Conversely, if I promise an article on SQL Server Internals to SSC, some people might assume I am talking from a position of expertise since SQL Server Internals are a complicated subject. But the truth is that I barely know enough to scratch the surface of this topic. So if I write such an article, the first thing I would tell people is "I'm new at this, but this is what I saw when I did X thing at my job." That way Gail, Tom, Jeff, and everyone else with more experience than me would (I hope) moderate their comments from "You are clueless" to more of a "Well, have you checked out this link that explains that behavior" or "You're misinterpreting your results."

    Not that any of them ever respond that way, but at least I'm setting the expectation at the start of the article so that people know where my POV is coming from. That's also why I would write my business case at the start. Giving the readers a starting point from which to view the code is more of a practical issue to me than it is any attempt at superiority.


    I understood Dwain to say that he elects not to start an article with a broad pronouncement that it is "written for beginners by a beginner" because maybe some readers who erroneously consider themselves above average in their knowledge of SQL Server (due to the illusory superiority phenomenon) would deem such an article unworthy of their attention and stop reading. That would be unfortunate, since those who wrongly think themselves to be above average in skill and knowledge tend to be the most in need of learning and do the most damage in their ignorance. Rather, as I read Dwain's explanation, he counts on those for whom the article is too basic to realize it and stop reading if they choose.

    Brandie, I didn't think that Dwain was suggesting that YOU suffer from the illusory superiority phenomenon, FWIW.

    Dwain, forgive me if I have misunderstood you and put words in your mouth.

    This is an interesting discussion. I plan to write on some SQL Server topics for the first time soon, and I'm glad to hear the various perspectives of those who have gone before me.

    Regards,
    Jason

    EDIT: Deleted a sentence where I mixed up who had said what. Sorry about that!


    Jason Wolfkill
    Blog: SQLSouth
    Twitter: @SQLSouth
    Post #1476571
    « Prev Topic | Next Topic »

    Add to briefcase «««4,0644,0654,0664,0674,068»»»

    Permissions Expand / Collapse