November 12, 2009 at 10:00 pm
Florian Reischl (11/12/2009)
I completely confirm Jeff! Some random values are really important to ensure some fine tests.I prefer this method:
😀
:-D:-D:-D:-D
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2009 at 1:22 am
Florian Reischl (11/12/2009)
I completely confirm Jeff! Some random values are really important to ensure some fine tests.I prefer this method:
😀
:hehe::-D:hehe::-D:hehe::-D
Thanks Flo for starting my day with a good laugh!
-- Gianluca Sartori
November 13, 2009 at 4:25 am
November 13, 2009 at 7:08 am
CirquedeSQLeil (11/12/2009)
Alvin Ramard (11/12/2009)
CirquedeSQLeil (11/12/2009)
amazing how the thread can make a day go from bad to better. At least one good laugh a day.At first I thought you said the thread went from bad to better. I was going to say: "What???"
Sorry if you're not having a good day. We try to make everybody's day better on here.
Oh the day got a whole lot better looking at the thread (and all the while not looking 🙂 ).
I have to fix doughhead mistakes by my predecessors. This person thought that AVG was interchangeable with SUM.
It is, AVG(1) = SUM(1). Mathematical certainty. 😀
**EDIT - Damn! Old joke already.....
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
November 13, 2009 at 7:12 am
Jeff Moden (11/12/2009)
Alvin Ramard (11/12/2009)
I wasn't being serious when I made a comment about an article.Jeff, Bob and I were out in the parking lot discussing what you just mentioned, about 45 minutes before you posted your comment.
So what did you guys come up with in that discussion?
#1 - SSC is a great place for people to improve their SQL knowledge.
#2 - The simple solutions are not always suitable when dealing with large tables. (This was related to random numbers and newid.)
#3 - It was getting chilly in the parking lot.
P.S. Bob, were you wearing a microphone? See Steve's editorial this morning.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
November 13, 2009 at 8:21 am
Alvin, I just looked read the editorial. Interesting coincidence. I did in fact have a microphone on me, as does everyone who carries a cell phone. The paranoid side of me is convinced that those microphones are always on ... and that "they" are always listening. Steve, may be one of the Powers That Be
(Dangit, where did I put my colander?)
Seriously, Steve, that is an excellent question you raised in today's editorial. Alvin and I really did ramble on to that topic last night. We agreed that VB bears a much closer resemblance to C# than it does to MS-Basic from the Paleolithic Era.
It will be interesting to see what results your poll produces. There is nothing at all wrong with C#, but it's human nature to go with what you know, which is usually what you learned first. Hopefully you will hear from people who have worked with both languages for a significant amount of time. But I suspect this will be very much like the MAC/PC debate.
Jeff, I'm sure you are aware that newID() has been used for random number generation in a couple of articles at least. While I understand you don't like to see pearls cast before swine, I wouldn't worry about it too much. There is a ton of information out there for anyone who cares enough to look. But not everyone cares enough to make the effort, or is quick enough to see the potential in what they read.
In any event, I'm grateful for all the pearls all you folks have shared.
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
November 13, 2009 at 8:55 am
I hope I'm not one of the Powers that be. If so, they might kick me out soon. I know I frustrate the higher ups at times. Definitely was always more of a worker advocate than a management advocate when I had to be in charge.
I like to think I'm a blue collar guy that got lucky in a white collar world.
November 13, 2009 at 8:59 am
finally done getting kids off and feeding the beasts around here. Lucky there's no wind. I'll check the poll now and see what I think of the temperature. I'd like to think that VB.NET works as well as C#, especially since there are a lot of VB people out there.
If any of you experts wants to tackle it, it would be great to see a series of where queries start to fail, or where they don't scale. When does a table that's growing start to cause issues in some queries. If I add 1,000,000 rows? 10,000,000? I'm sure we see queries cause QP changes over time. Would be nice to put some numbers around it and educate people about what to watch out for.
November 13, 2009 at 9:12 am
Steve, that's not a bad idea but isn't the answer usually "It depends?"
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
November 13, 2009 at 10:25 am
Agree, the answer to that question is - "It depends"
If we are using RBAR, on a 386, with 256MB Ram - I'm sure we could bring the house down with the query very quickly.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 13, 2009 at 11:01 am
Still thinking about Steve's idea, it really wouldn't hurt to post up cases where at some point an alternate technique performs faster. The "it depends" really applies to where and when you pass the "pain point." Not only table sizes, but indexes, joins and other stuff can affect that. But it really wouldn't hurt to illustrate the point so that newcomers would understand there isn't a "best" technique. At least they'll know to watch for a pain point as volumes go, and they'll have an alternative when it's time for a change.
I volunteer to do a writeup on row_number() to get the detail of the first row in a series (latest order for each customer) versus querying the max order date for each customer and joining back to the detail table.
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
November 13, 2009 at 11:24 am
It does depend, but you could take a reasonable server, say an x86 or x64 with 4GB of RAM, 2 cores, and try some common things. Maybe querying some order/order detail stuff, and noting when query plans change.
It wouldn't be an exact model, but it would be good information to know that the difference between 200 rows and 20,000,000 matters in how you write queries.
November 13, 2009 at 4:58 pm
Off topic: Hey Steve, is there anything that can be done to help George out here? It's just a small thing about user names and numbers.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
November 13, 2009 at 5:22 pm
Sent George a note. We'll sort him out.
November 13, 2009 at 11:48 pm
Steve Jones - Editor (11/13/2009)
Sent George a note. We'll sort him out.
Awesome Steve - thanks!
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
Viewing 15 posts - 9,226 through 9,240 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply