Writing Dynamic Stored Procedure

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Sunil Chandurkar » Writing Dynamic Stored Procedure

84 posts, Page 1 of 9

1 2 3 4 5 »»»

Writing Dynamic Stored Procedure

Rate Topic

Display Mode

Topic Options

Author

Message

Sunil Chandurkar

Posted Saturday, May 30, 2009 11:52 AM

SSC Veteran

Group: General Forum Members
Last Login: Thursday, September 27, 2012 4:24 AM
Points: 253, Visits: 78

Comments posted to this topic are about the item Writing Dynamic Stored Procedure

Post #726230

Carlo Romagnano

Posted Monday, June 01, 2009 12:56 AM

SSCommitted

Group: General Forum Members
Last Login: Today @ 1:10 AM
Points: 1,998, Visits: 1,866

Old style to write the WHERE condition.
I prefer to build a string ONLY with the true condition; it's more performing.
In a complex WHERE with useless condition may lead to a BIG consume of resources.

Post #726438

Rob Reid-246754

Posted Monday, June 01, 2009 1:26 AM

SSC Veteran

Group: General Forum Members
Last Login: Monday, January 21, 2013 7:23 AM
Points: 205, Visits: 363

Quick question is it only me or has the formatting of that article gone a bit haywire. I'm sure there shouldn't be HTML formatting tags appearing alongside the SQL example.

I used to use lots of CASE statements and IF branches to handle queries that needed to be dynamic but build on the server side using multiple proc params. For example something like this:

CREATE PROC test
@Stamp datetime,
@FirstName varchar(25) = NULL,
@Surname varchar(25) = NULL,
@Age int = NULL,
@Address1 varchar(40) = NULL

AS
BEGIN

DECLARE @Today BIT

SELECT @Today = CASE Datediff(day,@Stamp,getdate()) WHEN 0 THEN 1 ELSE 0 END

IF @Today = 1
BEGIN
SELECT FirstName, SureName, Age, Address1
FROM DAILY
WHERE FirstName = CASE WHEN @FirstName IS NULL THEN FirstName ELSE @FirstName END
AND Surname = CASE WHEN @Surname IS NULL THEN Surname ELSE @Surname END
AND Age = CASE WHEN @Age IS NULL THEN Age ELSE @Age END
AND Address1 = CASE WHEN @Address1 IS NULL THEN Address1 ELSE @Address1 END
END
ELSE
BEGIN
SELECT FirstName, SureName, Age, Address1
FROM HISTORICAL
WHERE FirstName = CASE WHEN @FirstName IS NULL THEN FirstName ELSE @FirstName END
AND Surname = CASE WHEN @Surname IS NULL THEN Surname ELSE @Surname END
AND Age = CASE WHEN @Age IS NULL THEN Age ELSE @Age END
AND Address1 = CASE WHEN @Address1 IS NULL THEN Address1 ELSE @Address1 END

END

But then I learnt a bit more about query plan caching and indexing and so if I have to do dynamic queries in the DB I would build them up using a string with only the columns and filters required and then use sp_executeSQL to run it.

Post #726447

Gerard van de Ven

Posted Monday, June 01, 2009 2:16 AM

Grasshopper

Group: General Forum Members
Last Login: Tuesday, June 11, 2013 7:37 AM
Points: 17, Visits: 56

Apart from the fact that this article is horribly mangled (which may of course not be the author's fault, but it doesn't help in making this article easily readable), it is also a rather bad advice. And I know because I had done the same a while ago but got corrected.

For details see http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries

Post #726460

Boban Stojanovski-455883

Posted Monday, June 01, 2009 2:22 AM

Valued Member

Group: General Forum Members
Last Login: Thursday, April 18, 2013 5:09 AM
Points: 59, Visits: 93

I prefer to use Sunil's way of writing query when I have optional (can be null) parameters in the procedure. I don't see a logical reason to use CASE, or ISNULL statement.
Sunil example is not anything new. Like anything in live, this too have some good and bad sides. The good ones are that is very logical, easy to debug, don't have a problem of sql injection etc. But also have bad side like the one that it can't use the cached plan for the query. In the other side creating query dinamically as string and executing with sp_executesql have all the bad sides but one good and that is that can use cashed plan. In most of situation we should use the first one, becuase if has more good than bad sides. But it becomes very usefull to use second one when we search very big table with milions of records.

Post #726464

Dave Ballantyne

Posted Monday, June 01, 2009 2:52 AM

SSCommitted

Group: General Forum Members
Last Login: Tuesday, May 28, 2013 3:05 AM
Points: 1,943, Visits: 8,229

http://www.sommarskog.se/dyn-search-2005.html discusses this and many other similar methods

Clear Sky SQL
My Blog
Kent user group

Post #726476

thom smith-433882

Posted Monday, June 01, 2009 3:02 AM

Forum Newbie

Group: General Forum Members
Last Login: Thursday, May 06, 2010 2:13 AM
Points: 2, Visits: 8

Yes, it is not good way to write dynamic procedures like this because of performance, but on other side this approach has one plus - it is good readable, so easy to understand when looking on code of procedure. Times ago i was doing it same way, but once database was growing much the penalties for uising this procedures were big.

Post #726480

RichB

Posted Monday, June 01, 2009 3:05 AM

Ten Centuries

Group: General Forum Members
Last Login: Tuesday, June 11, 2013 5:24 AM
Points: 1,028, Visits: 759

Excellent link Dave.

I had been going to say I could never get the @x = y or @x is null thing to work effectively - it always ends up scanning big tables rather than using decent indexes, but Erland seems to cover the whole subject in very good depth.

Post #726481

Dave Ballantyne

Posted Monday, June 01, 2009 3:54 AM

SSCommitted

Group: General Forum Members
Last Login: Tuesday, May 28, 2013 3:05 AM
Points: 1,943, Visits: 8,229

http://www.sommarskog.se/dynamic_sql.html This one is also very good discussing dynamic sql in general. Coincidently I posted to my blog a method for optimizing dynamic sql for Unbalanced data loads http://sqlandthelike.blogspot.com

Clear Sky SQL
My Blog
Kent user group

Post #726499

Noel McKinney

Posted Monday, June 01, 2009 5:42 AM

SSCrazy

Group: General Forum Members
Last Login: Thursday, April 05, 2012 2:35 PM
Points: 2,007, Visits: 767

Gail's article a few month's back on catch-all queries covered this territory really well:

http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries

Sunil's method is acceptable on small tables, but on larger tables this will choke a server. I think developers implement it in their test environment where tables have a thousand rows, and it does what it's supposed to do and returns quickly. So it goes to production where the million row tables are first encountered. That's when the stored procedure that runs in under a second during testing takes hours in actual use. Clustered index scan fun at its best. Tongue

Post #726543

« Prev Topic | Next Topic »

84 posts, Page 1 of 9

1 2 3 4 5 »»»

Permissions