Viewing 15 posts - 58,591 through 58,605 (of 59,091 total)
BANG!
I'm dead. You guys finally proved your point with some cold, hard facts. I didn't like Carl's test the way it was because...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2005 at 9:43 pm
Greg Wrote: Go ahead and use your Scalar UDFs on large datasets, and one day if the set becomes large enough, you will be re-evaluating those UDFs.
Allow me to quote...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2005 at 9:22 pm
Here's the late night (quiet server) run times for 25K rows...
------------------------------
Function in SELECT
------------------------------
Formula in WHERE
------------------------------
Function in WHERE
------------------------------
==============================
Function in SELECT
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2005 at 7:30 am
Ah... now I see
... it was 200k rows, not 2M rows... too late at night... It does support what we said earlier......
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2005 at 9:56 pm
No fair!
You used a real server with the Enterprise Edition... I used a pc with the Developer's Edition! ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2005 at 7:35 pm
Well, they say one measurement is worth a thousand speculations.... so, I did one. I'll have to eat a little crow on the "clearly they are not slower" thing but...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 5, 2005 at 8:25 pm
Harley,
That's an outstanding idea! Thank you. It's nice to see people treating SQL as a computer language instead of just a repository. I do have a couple of suggestions, though...
1....
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 10:06 pm
Serqiy, that was my finding, as well. I was being conservative considering the volitile subject.
My thought is that properly written UDF's are much too valuable to simply write off...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 7:59 pm
Outstanding, Sergiy!
I ran the following and the proc that uses the DateOnly function doesn't take any longer than the other...
USE NORTHWIND
GO
SET STATISTICS TIME ON
GO
CREATE PROCEDURE dbo.ProcTest1 AS
SELECT dbo.DateONLY(ShippedDate)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 4:21 pm
>The conclusion I am reaching is why you should never, ever, under any circumstances use UDFs. e.g. DENY CREATE FUNCTION to public should be standard.
My experience is that UDF's are...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 3:30 pm
Charles,
Very nice. And if you reverse the dates, the numbers make even more sense! I added a couple more to show the trend...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2005 at 11:07 pm
Not sure... I think this is what you want... make sure you have a primary key on your table and this should only take a couple of seconds to run. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2005 at 10:41 pm
Those are all great methods and I applaud the innovations of all... but as Remi G and Adam Mechanic would remind us, you might just want to think about finally...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2005 at 12:27 am
Nice article... you really put some thought into the proofs and which graphics to use. Good idea, as well.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2005 at 8:05 pm
They want to use a varbinary similar to what is presented by COLUMNS_UPDATED() in triggers. I've got all that worked out so no problem there. Like I said, I have...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2005 at 7:58 pm
Viewing 15 posts - 58,591 through 58,605 (of 59,091 total)