Just Walk Away - Blacklisting - and Twits without Twitter

  • Jeff Moden (4/12/2009)


    I've been known to stop an interview after the first question for those same reasons. I've no tolerance for condescending or arrogant people especially where I work. Even if you're a bloody genius, you have to get along with the other people. Of course, giving the wrong answer on top of all that is instant grounds for a rapid fire volley of pork chops followed by an immediate military escort off the premises.

    I can handle wrong answers much better than any form of arrogance. Confidence is good. Anyone who doesn't know the difference needs to do some serious soul searching.

    My main issue with the person in question was that while I was the one asking the questions, he directed every single answer to my colleague (who was sitting a couple seats away). It's as if I was beneath his notice. Since he would have been working with me if hired, it did not leave a good impression.

    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
  • And Jeff, don't think about canceling a book because someone found a different solution. There needs to be multiple ways to do things, and even if it's not the most efficient, it's likely better than what most people write. You could also reference another solution, or even get a chapter from a co-writer on a better way to do things.

  • Steve Jones - Editor (4/13/2009)


    And Jeff, don't think about canceling a book because someone found a different solution. There needs to be multiple ways to do things, and even if it's not the most efficient, it's likely better than what most people write. You could also reference another solution, or even get a chapter from a co-writer on a better way to do things.

    Heh... actually, it turns out that nothing has really changed. VARCHAR(MAX) is tough on Tally table and other pseudo-cursor solutions for a number of reasons. On VARCHAR(8000), both still rule. In some of the testing done, the Tally table solution came very close to CLR speeds for splits.

    --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)

  • GilaMonster (4/13/2009)


    My main issue with the person in question was that while I was the one asking the questions, he directed every single answer to my colleague (who was sitting a couple seats away). It's as if I was beneath his notice. Since he would have been working with me if hired, it did not leave a good impression.

    Pork chops, Gail... you gotta remember to take a load of pork chops to interviews. 😉

    There's no excuse for what I think may have been cultural arrogance in this world today. But, that's one of the real purposes of an interview... the search for "tics" and "triggers".

    I sure feel bad that good folks like you (heh... and me... I'm old) have to go through such a thing. People can be so rude and ill-mannered.

    --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)

  • VARCHAR(MAX) is tough on Tally table and other pseudo-cursor solutions for a number of reasons.

    So the answer is "It depends." No doubt you will be honest enough to include those known exceptional cases in your book, making it even more valuable. Go ahead on.

    __________________________________________________

    Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
    Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills

  • Jeff Moden (4/16/2009)


    Heh... actually, it turns out that nothing has really changed. VARCHAR(MAX) is tough on Tally table and other pseudo-cursor solutions for a number of reasons. On VARCHAR(8000), both still rule. In some of the testing done, the Tally table solution came very close to CLR speeds for splits.

    Detailed performance results:

    http://www.sqlservercentral.com/Forums/FindPost697144.aspx

    The tally was 37% slower on the 'short' test, I think. Admittedly, the differences are only important for larger strings with a relatively low occurrence of delimiters. One could argue both ways based on the results:

    1. Ultimately, CLR is faster than the tally solution in all tested cases. The difference varies from slight to remarkable.

    2. The added complexity of CLR is probably not justified in any but the most extreme cases.

    3. A tally solution remains an elegant, if somewhat brute-force, solution.

    4. The tally solution is arguably easier to implement, has no external dependencies (such as policies on enabling CLR), and is easily re-used for other problems which suit it.

    ...and so on.

    🙂 Paul

    Short answer: write the book!

  • Paul White (4/16/2009)


    3. A tally solution remains an elegant, if somewhat brute-force, solution.

    Thanks for the confidence on the book, Paul. I am curious though... you keep saying that the Tally solutions are "brute-force"... other than using a CLR, what are you comparing it to for you to give it such a label? Or, are you just talking about the fact that it basically scans each character using SUBSTRING rather than the more elegant positional use of CHARINDEX looping solutions?

    --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)

  • Jeff Moden (4/16/2009)


    Paul White (4/16/2009)


    3. A tally solution remains an elegant, if somewhat brute-force, solution.

    Thanks for the confidence on the book, Paul. I am curious though... you keep saying that the Tally solutions are "brute-force"... other than using a CLR, what are you comparing it to for you to give it such a label? Or, are you just talking about the fact that it basically scans each character using SUBSTRING rather than the more elegant positional use of CHARINDEX looping solutions?

    Yes - the last part. CHARINDEX seeks to the desired delimiter as you say, whereas the tally does a SUBSTRING and compare for every character in the searched string.

    I will happily adopt a less emotive term if someone suggests a good replacement for 'brute force' 😉

  • Paul White (4/16/2009)


    I will happily adopt a less emotive term if someone suggests a good replacement for 'brute force' 😉

    Heh... nope... now that I understand what you mean, not necessary. I was just getting whiplash between the words "elegant" and "brute force". 😀

    --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)

  • Jeff Moden (4/16/2009)


    Heh... nope... now that I understand what you mean, not necessary. I was just getting whiplash between the words "elegant" and "brute force". 😀

    I see what you mean (reading it back) - the brain sort of stumbles at the disconnect between the two!

    Oh well.

    Hey, I'll swap you a copy of your book for a good beginner's guide to C#

    :laugh::w00t::laugh:

    edit for spacing

  • Jeff Moden (4/16/2009)


    Steve Jones - Editor (4/13/2009)


    And Jeff, don't think about canceling a book because someone found a different solution. There needs to be multiple ways to do things, and even if it's not the most efficient, it's likely better than what most people write. You could also reference another solution, or even get a chapter from a co-writer on a better way to do things.

    Heh... actually, it turns out that nothing has really changed. VARCHAR(MAX) is tough on Tally table and other pseudo-cursor solutions for a number of reasons. On VARCHAR(8000), both still rule. In some of the testing done, the Tally table solution came very close to CLR speeds for splits.

    I hopefully get an honorable mention for stumbling on that little bit of info. You seemed a little shocked when the tally table stumbled.

  • I knew it would stumble on VARCHAR(MAX)... I just didn't realize how bad. However, on the thread that Flo has been orchestrating, he sent me a PM with some nasty fast Tally table code on the VARCHAR(MAX) problem. I did a pretty deep analysis and it turns out that it's not the code he's using that makes it so fast... it's... nah... can't steal the thunder. He's in the process of writing up what we found. It also makes the standard Tally table solution beat the pants off of everything else. You'll see.

    --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)

  • Jeff Moden (4/20/2009)


    I knew it would stumble on VARCHAR(MAX)... I just didn't realize how bad. However, on the thread that Flo has been orchestrating, he sent me a PM with some nasty fast Tally table code on the VARCHAR(MAX) problem. I did a pretty deep analysis and it turns out that it's not the code he's using that makes it so fast... it's... nah... can't steal the thunder. He's in the process of writing up what we found. It also makes the standard Tally table solution beat the pants off of everything else. You'll see.

    Can't wait! Well, I guess I'll have too, though, won't I.

  • You're a cruel man, Jeff. I'm also on pins and needles. Is he going to post it in the tally thread, or do we have to wait for his article?

    __________________________________________________

    Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
    Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills

  • The rumour is that Jeff has been busy porting the .NET common language runtime to T-SQL/native client.

    T-SQL.Net - might catch on...?

    Just kidding Jeff - I can't wait to see it either!

Viewing 15 posts - 61 through 75 (of 78 total)

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