|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Monday, April 29, 2013 6:17 AM
Points: 15,
Visits: 53
|
|
What about this approach?
SELECT [Name], [Color], [ListPrice], [ModifiedDate] FROM [Production].[Product] WHERE (@Name IS NULL OR [Name] LIKE @Name) AND (@Color IS NULL OR [Colour] LIKE @Color) AND (@ListPriceMin IS NULL OR [ListPrice] >= @ListPriceMin) AND (@ListPriceMax IS NULL OR [ListPrice] <= @ListPriceMax) AND (@ModifiedDateMin IS NULL OR [ModifiedDate] >= @ModifiedDateMin) AND (@ModifiedDateMax IS NULL OR [ModifiedDate] <= @ModifiedDateMax)
By adding first IS NULL parameter checking, logically the second condition after OR should not be checked if first one is TRUE.
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 3:44 PM
Points: 1,786,
Visits: 3,323
|
|
mohd.nizamuddin (5/20/2010) Very well written, a nice article.
Can you please put some light on the excution plan of this SP, while writing dynamic SQL.
As per knowledged, the execution plan won't be resued.
Please suggest.Execution plans will be cached when using dynamic SQL, and SQL Server will cache a separate plan for each combination of the values in the parameters for sp_executesql.
To test that this actually works I suggest you run Profiler and add SP:CacheHit, SP:CacheMiss and SP:CacheInsert events when you use sp_executesql.
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Friday, July 29, 2011 4:14 AM
Points: 318,
Visits: 198
|
|
Nils Gustav Stråbø (5/20/2010)
mohd.nizamuddin (5/20/2010) Very well written, a nice article.
Can you please put some light on the excution plan of this SP, while writing dynamic SQL.
As per knowledged, the execution plan won't be resued.
Please suggest.Execution plans will be cached when using dynamic SQL, and SQL Server will cache a separate plan for each combination of the values in the parameters for sp_executesql. To test that this actually works I suggest you run Profiler and add SP:CacheHit, SP:CacheMiss and SP:CacheInsert events when you use sp_executesql.
Thanks for your prompt response.
Just going through http://www.sommarskog.se/dynamic_sql.html and I got the idea.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Thursday, March 14, 2013 4:15 AM
Points: 3,240,
Visits: 4,960
|
|
Dynamic SQL is the last thing to do. I use and prefer the following way;
SELECT [Name], [Color], [ListPrice], [ModifiedDate] FROM [Production].[Product] WHERE ([Name] LIKE case when @Name is Null then [Name] else @Name end) AND ([Color] LIKE case when @Color is Null then [Color] else @Color end) AND ([ListPrice] >= case when IsNull(@ListPriceMin,0) = 0 then [ListPrice] else @ListPriceMin end) AND ([ListPrice] <= case when IsNull(@ListPriceMax,0) = 0 then [ListPrice] else @ListPriceMax end) AND (ModifiedDate >= case when @ModifiedDateMin is Null then ModifiedDate else @ModifiedDateMin end) AND (ModifiedDate <= case when @ModifiedDateMax is Null then ModifiedDate else @ModifiedDateMax end)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Sometimes, winning is not an issue but trying. You can check my BLOG here
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 3:44 PM
Points: 1,786,
Visits: 3,323
|
|
Atif Sheikh (5/20/2010) Dynamic SQL is the last thing to do Dymamic SQL is the only efficient way (in my knowledge) to solve the problem with multiple optional parameters. Whether you use CASE, COALESCE, ISNULL or OR to try to avoid dynamic SQL, you will most likely (if not always) end up with index scans. I have never seen the methods mentioned above work in a performance perspective. Look at your execution plan the next time you try a MyCol=case when @val is null then MyCol else @val end. You will see a index scan, not a seek (if the column is indexed).
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Thursday, May 16, 2013 8:29 AM
Points: 4,804,
Visits: 8,067
|
|
Nils Gustav Stråbø (5/20/2010)
Atif Sheikh (5/20/2010) Dynamic SQL is the last thing to doDymamic SQL is the only efficient way (in my knowledge) to solve the problem with multiple optional parameters. Whether you use CASE, COALESCE, ISNULL or OR to try to avoid dynamic SQL, you will most likely (if not always) end up with index scans. I have never seen the methods mentioned above work in a performance perspective. Look at your execution plan the next time you try a MyCol=case when @val is null then MyCol else @val end. You will see a index scan, not a seek (if the column is indexed).
Ditto. See what Gail Shaw writes about this topic: http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/.
Get your two-cent-answer quickly The Spaghetti DBA
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 3:44 PM
Points: 1,786,
Visits: 3,323
|
|
My experience is that developers (who doesn't understand how a DBMS executes a query and have never heard of execution plans) write the queries on tables with small number of test rows. When they see that it works, and quite fast because of the small numbers of rows, they are happy with it and puts it to production. A year or two later, when the amount of data has grown large, the start to get complaints from the users because things are slow.
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: 2 days ago @ 5:49 AM
Points: 202,
Visits: 1,043
|
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Monday, June 18, 2012 12:52 AM
Points: 1,
Visits: 18
|
|
I don't see why you guys are promotiing the use of dynamic SQL. I'm often asked in job interviews when it's appropriate to use dynamic SQL - the correct answer is never.
I have never (and will never) see dynamic SQL out perform a properly coded & compiled stored procedure. It's impossible - NOTHING gets cached.
Regards,
Brett Robson
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: Thursday, May 16, 2013 8:29 AM
Points: 4,804,
Visits: 8,067
|
|
Brett Robson (5/20/2010) I don't see why you guys are promotiing the use of dynamic SQL. I'm often asked in job interviews when it's appropriate to use dynamic SQL - the correct answer is never.
I have never (and will never) see dynamic SQL out perform a properly coded & compiled stored procedure. It's impossible - NOTHING gets cached.
"Never" and "Always" hardly apply to the database world. "It depends" fits better.
You have two possibilities: 1) Keep your idea that dynamic sql is evil and should never be used 2) Read the excellent articles (especially Erland Sommarskog's and Gail Shaw's blogs) that were linked in this thread and try to learn something The coiche is yours.
Get your two-cent-answer quickly The Spaghetti DBA
|
|
|
|