Viewing 15 posts - 47,791 through 47,805 (of 59,099 total)
Alvin Ramard (10/6/2008)
Someone slap me please! All I keep thing about is using a ...... cursor.
Slap... slap, slap... [font="Arial Black"]SLAP![/font]
Heh... Pork chops away!!! 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 9:41 pm
Mike (10/11/2008)
PaulB (10/11/2008)
CIO
|___ PMO
|
|___ Infrastructure
| |
| ...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 8:17 pm
Garadin (10/10/2008)
The IN clause is actually faster than the multiple joins. I tested it on the Northwind database (so it was easily repeatable) as so:
I ran your test code...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 8:07 pm
This is a cross post. Please don't post solutions here. Go to the following post, instead...
http://www.sqlservercentral.com/Forums/Topic584480-338-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 7:57 pm
If you want to return a table's worth of splits, then you have to stop worrying about the rows and worry only about the column. 😀
I don't know...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 7:55 pm
And I disagree because RI isn't the only reason to have a PK. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 3:32 pm
Heh... and by the way... this...
T - you do whatever transformation or massaging is needed...
... sometimes means deleting duplicated data. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 2:54 pm
PaulB (10/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 2:51 pm
GilaMonster (10/11/2008)
Jeff Moden (10/11/2008)
... and, here's the tests... these work on both 2k and 2k5. According to Gail's fine blog, some of these tests will not work on 2k8...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 2:42 pm
rbarryyoung (10/10/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 2:25 pm
PaulB (10/11/2008)
How about staging tables in a Data Warehouse environment?
As you should know Staging tables are nothing...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 11:58 am
Outstanding explanation, Kenney.
On the recursive thing... do keep in mind that recurssion is nothing more than a loop and has the same performance impedements as a loop. In other...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 11:33 am
Except for things like what Marios pointed out, I avoid table variables like the plague not only because of their "single record" execution plan, but because they are also more...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 11:20 am
Guess I'll throw the testing I've done in the past into the ring... 🙂
The testing below takes the "display" out of the picture using a throw-away variable of the DATETIME...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 11:11 am
Chris Harshman (10/10/2008)
Gary Johnson (10/10/2008)
It would be interesting to see what performed better. 😉
Actually the DateAdd/DateDiff method seems to perform slightly better (like 6 milliseconds better over 25,000 rows) than...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 11, 2008 at 10:09 am
Viewing 15 posts - 47,791 through 47,805 (of 59,099 total)