Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2005
»
SQL Server 2005 Performance Tuning
»
CASE statement versus dynamic Query
17 posts, Page 2 of 2
««
1
2
CASE statement versus dynamic Query
Rate Topic
Display Mode
Topic Options
Author
Message
Marios Philippopoulos
Marios Philippopoulos
Posted Tuesday, February 26, 2008 12:31 AM
SSCommitted
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 7:10 AM
Points: 1,824,
Visits: 3,477
As Jack mentioned earlier, do use
sp_executesql
in your dynamic SQL for efficient reuse of execution plans.
Even with the 100 possible columns involved here, I'm sure a handful of favorites will take the bulk of choices for sorting, and you will want these execution plans to be re-used as much as possible.
__________________________________________________________________________________
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #460083
Jeff Moden
Jeff Moden
Posted Tuesday, February 26, 2008 7:11 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 6:23 AM
Points: 32,903,
Visits: 26,784
Marios Philippopoulos (2/26/2008)
As Jack mentioned earlier, do use
sp_executesql
in your dynamic SQL for efficient reuse of execution plans.
Even with the 100 possible columns involved here, I'm sure a handful of favorites will take the bulk of choices for sorting, and you will want these execution plans to be re-used as much as possible.
I'd have to say, it depends... I've seen it where reuse of the execution plan gives some horrible performance because of the change in selection method caused by the parameter change. I've recently run into that very problem where the recompile produces the correct answer using a merge join on a million rows in milliseconds as opposed to a half hour long run using a looped join.
sp_ExecuteSQL isn't the panacea that some think it is... it's sometimes better to have a recompile occur.
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #460221
Matt Miller (#4)
Matt Miller (#4)
Posted Tuesday, February 26, 2008 7:30 AM
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 6:49 PM
Points: 6,998,
Visits: 13,946
I'd have to agree that you'd probably be better off just telling it to recompile each time. In a case like this, unless your usage is very biased towards one specific set of columns being ordered - it will actually save you time, since the optimizer won't have to spend any time trying to figure out if it can use the old plan (which it might try to use even if it's not so good for what is going on now).
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #460232
Marios Philippopoulos
Marios Philippopoulos
Posted Tuesday, February 26, 2008 11:41 AM
SSCommitted
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 7:10 AM
Points: 1,824,
Visits: 3,477
Good points guys, thanks.
__________________________________________________________________________________
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #460445
sergeyledenev
sergeyledenev
Posted Saturday, February 04, 2012 5:55 PM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, February 08, 2012 4:53 PM
Points: 110,
Visits: 12
Might be out of scope, but on my last job I was issued to create the similar table structure to keep there the contact information. The demand was in order to keep the different contact schemas in the same table.
I've gone with the other approach (it was not too easy to get the boss' agreement
)
Instead of the single table with contact information I've implemented the structure of 2 tables: the contact and contact_details. The contact_details has 3 columns: contact_id, value and value_type_id.
That all allowed me to avoid such problems as sorting. And has used the storage more efficient way.
Post #1246945
Jeff Moden
Jeff Moden
Posted Saturday, February 04, 2012 11:56 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 6:23 AM
Points: 32,903,
Visits: 26,784
sergeyledenev (2/4/2012)
Might be out of scope, but on my last job I was issued to create the similar table structure to keep there the contact information. The demand was in order to keep the different contact schemas in the same table.
I've gone with the other approach (it was not too easy to get the boss' agreement
)
Instead of the single table with contact information I've implemented the structure of 2 tables: the contact and contact_details. The contact_details has 3 columns: contact_id, value and value_type_id.
That all allowed me to avoid such problems as sorting. And has used the storage more efficient way.
Depending on the number of nullable "columns", I agree that's one way to use storage more efficiently. I don't understand how using such an EAV table would allow you to avoid sorting problems, though. In fact it would seem to exacerbate the problem a bit. For example, if the EAV contained a FirstName, LastName, and PhoneNumber, how would you sort based on LastName and FirstName?
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1246961
sergeyledenev
sergeyledenev
Posted Wednesday, February 08, 2012 4:41 PM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, February 08, 2012 4:53 PM
Points: 110,
Visits: 12
I was using the xml format for the output. Tha app sorted the set by itself. The major benefit is the indexed value field - which is any of the contact's info.
As there should be the reasonable amount of records - the task is affordable for the app
Post #1249402
« Prev Topic
|
Next Topic »
17 posts, Page 2 of 2
««
1
2
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.