Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Usage of Functions in Stored Procedures Expand / Collapse
Author
Message
Posted Monday, April 28, 2008 11:57 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 9:36 PM
Points: 836, Visits: 76
Comments posted to this topic are about the item Usage of Functions in Stored Procedures
Post #491840
Posted Tuesday, April 29, 2008 1:01 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 16, 2014 4:46 AM
Points: 5,415, Visits: 1,400
The article was nice. I hopoe the code is right. But when I tried to run the code I am getting error in the Insert statement.

BEGIN

INSERT INTO CaseDetail VALUES(200,300,1)

SET @count = @count -1

END


I am not having time to check the error but do we require to write the column names in the syntax. I may done some silly mistakes also.




Post #491860
Posted Tuesday, April 29, 2008 2:11 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, March 27, 2009 4:01 AM
Points: 14, Visits: 40
The final select statement where you use a local variable is different to the pure select statement, it only works because you've got all the values exactly the same. So the examples you give are broken because you've been lazy and used exactly the same values.

If your data really is like that something's wrong with the data structure.

All this article shows is how you should never use functions unless you know exactly what they do, precisely the opposite of what you say at the beginning. In this case the function is so useless you might as well throw it away.

My attitude with functions is avoid like the plague, as they break the rule of thinking in sets while programming SQL.
Post #491890
Posted Tuesday, April 29, 2008 2:43 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 9:36 PM
Points: 836, Visits: 76
Hi Paul,

The following chunk of code worked fine for me.

CREATE TABLE CaseDetail (CaseId INT IDENTITY(1,1), QTY NUMERIC(14,4), weightedQty NUMERIC(14,4), ShipmentId INT)

--We assume that these cases belongs to Shipment with id 1

DECLARE @count INT
SET @count =15000

WHILE (@count >0)
BEGIN
INSERT INTO CaseDetail VALUES(200,300,1)
SET @count = @count -1
END

select count(caseid) from CaseDetail

Thank you and have a nice day,
Sreeju
Post #491909
Posted Tuesday, April 29, 2008 5:09 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 2, 2013 12:15 PM
Points: 1,443, Visits: 711
There may be a few instances where functions can speed things along, I've found most of the time they hinder performance instead of helping it.

The times they've been useful to me is when I inherit something that's been designed poorly, and theres no $$$ to redesign it, but I have to make something work.
Post #491971
Posted Tuesday, April 29, 2008 5:12 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, October 16, 2014 4:46 AM
Points: 5,415, Visits: 1,400
Hi Sreeju

I may be wrong. May typed wrongly. I will check it again. Thnks for the info ......



Post #491974
Posted Tuesday, April 29, 2008 5:37 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 8:05 PM
Points: 13,925, Visits: 28,318
I've been burned way too many times by poor use of functions to be any kind of advocate for them. However, if you really want to drill down on them, then I recommend Andy Novick's book. He covers appropriate use of functions very well.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #491991
Posted Tuesday, April 29, 2008 7:34 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Sunday, August 17, 2014 3:10 PM
Points: 2,787, Visits: 6,098
My own rule of thumb is to avoid functions that contain queries. Yes, they make for easy reading, but it's far too likely that they will get and reused in SELECT queries. RBAR bad.

__________________________________________________

Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? -- Stephen Stills
Post #492086
Posted Tuesday, April 29, 2008 8:06 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, August 20, 2014 11:15 AM
Points: 45, Visits: 146
What about matrix type calculations?
How can they be accelerated?
What I mean is you have a bunch (about a dozen) of tables with charts of tax rates,freight rates, etc.
Each row will have different values from each table and then they get computed for the final result.
We have functions for various lookups and calculations, some will be repeated, some won't
How can you improve this type of process?
I can see your technique for the 1 function, but I'm not sure how it will scale in a large stored proc with lots of function calls and computations.
Post #492135
Posted Tuesday, April 29, 2008 8:08 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: 2 days ago @ 6:52 AM
Points: 870, Visits: 909
I don't know.... I've run both your inline and variable procedures and on my machine they both take about 470ms, give or take a few ms. In fact, if anything I've found the variable method slightly slower by up to 50ms.

Did you dropcleanbuffers before running each procedure? If not then you might find that the cached results are interfering with your numbers.

Also, if you check out the io statistics, more logical reads are performed with the variable method.

I'm not sure I see the benefit in running the exact same query twice, as you're doing in the variable method. Unless I'm missing something, which is quite possible ;)


Karl
source control for SQL Server
Post #492139
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse