April 13, 2009 at 2:58 am
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
April 13, 2009 at 7:14 am
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.
April 16, 2009 at 7:11 pm
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
Change is inevitable... Change for the better is not.
April 16, 2009 at 7:22 pm
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
Change is inevitable... Change for the better is not.
April 16, 2009 at 7:29 pm
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
April 16, 2009 at 7:35 pm
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
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 16, 2009 at 7:49 pm
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
Change is inevitable... Change for the better is not.
April 16, 2009 at 7:56 pm
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
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 16, 2009 at 8:00 pm
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
Change is inevitable... Change for the better is not.
April 16, 2009 at 8:05 pm
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
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 16, 2009 at 8:16 pm
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.
April 20, 2009 at 8:54 pm
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
Change is inevitable... Change for the better is not.
April 20, 2009 at 10:57 pm
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.
April 21, 2009 at 8:11 am
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
April 21, 2009 at 8:53 am
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!
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
Viewing 15 posts - 61 through 75 (of 78 total)
You must be logged in to reply to this topic. Login to reply