Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Dynamic Filter and Order By


Dynamic Filter and Order By

Author
Message
TomThomson
TomThomson
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10743 Visits: 12019
Sean Lange (10/3/2012)

... Isn't LIKE as good as >= for index seeks?!?


NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.

Actually LIKE is sargable when the pattern expression reduces to matching an initial substring, provided of course the pattern expression is unicode when the column is unicode and not unicode when the column is not unicode; so it doesn't prevent index scans.
(I remember thisone because it's half of a weird inconsistency: using LIKE to match an initial substring is sargable, while using LEFT is not ;-))
edit:spelling

Tom

Eugene Elutin
Eugene Elutin
Hall of Fame
Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)Hall of Fame (3K reputation)

Group: General Forum Members
Points: 3042 Visits: 5478
PiMané (10/3/2012)
Sean Lange (10/3/2012)
NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.


So a LIKE 'M%' is better replaced with a >= 'M' AND < 'N'..


No, that is wrong! LIKE 'M%' is SARGable, you don't need to replace it with such a mess

However, LIKE '%M' is not SARGable!. But replacing it with comparison operators will be quite problematic :-D.
If you really need the best possible performance for text searches like the above, there is SQL Server feature called Full Text Search. http://msdn.microsoft.com/en-us/library/ms142571.aspx
It's designed for performing effective comprehensive text searches.

_____________________________________________
"The only true wisdom is in knowing you know nothing"
"O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!":-D
(So many miracle inventions provided by MS to us...)

How to post your question to get the best and quick help
Sean Lange
Sean Lange
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16626 Visits: 17024
L' Eomot Inversé (10/4/2012)
Sean Lange (10/3/2012)

... Isn't LIKE as good as >= for index seeks?!?


NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.

Actually LIKE is sargable when the pattern expression reduces to matching an initial substring, provided of course the pattern expression is unicode when the column is unicode and not unicode when the column is not unicode; so it doesn't prevent index scans.
(I remember thisone because it's half of a weird inconsistency: using LIKE to match an initial substring is sargable, while using LEFT is not ;-))
edit:spelling


Thanks for the clarification Tom.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
PiMané
PiMané
Mr or Mrs. 500
Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)

Group: General Forum Members
Points: 592 Visits: 1334
Hi,

Regarding Dynamic SQL....
Instead of a SELECT suppose I have an UPDATE used on a SP.
The SP receives 6 parameters: @RecordId, @Col1Value, @Col2Update, @Col2Value, @Col3Update, @Col3Value...
Col1 is always updated but Col2 and Col3 are only updated if Col2Update and Col3Update are true (1).
Should dynamic SQL be used here as well?
I could write

UPDATE table SET
Col1 = @Col1Value,
Col2 = CASE WHEN @Col2Update = 1 THEN @Col2Value ELSE Col2 END,
Col3 = CASE WHEN @Col3Update = 1 THEN @Col3Value ELSE Col3 END
WHERE Id = @RecordId


but this would make Col2 and Col3 always be updated no matter what, even if the value is themselves...
also it's possible to write:

UPDATE table SET Col1 = @Col1Value WHERE Id = @RecordId
IF @Col2Update = 1
UPDATE table SET Col2 = @Col2Value WHERE Id = @RecordId
....


This would make another seek and update row and if the table had an UPDATE trigger it would fire the trigger again...
Back to the 1st case if there was also a trigger with the condition IF UPDATED(Col2) the condition would always be true...
There also the long solution:

IF @Col2Update = 1 AND @Col3Update = 1
....
ELSE
IF @Col2Update = 1
ELSE
.....
IF @Col3Update = 1
.....
ELSE
...


This is long and if necessary to add another column it would even longer... 2^[optional parameters]..

So is dynamic SQL a good option for this case too?!

Thanks,
Pedro



If you need to work better, try working less...
TomThomson
TomThomson
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10743 Visits: 12019
PiMané (10/4/2012)
Regarding Dynamic SQL....
Instead of a SELECT suppose I have an UPDATE used on a SP.
The SP receives 6 parameters: @RecordId, @Col1Value, @Col2Update, @Col2Value, @Col3Update, @Col3Value...
Col1 is always updated but Col2 and Col3 are only updated if Col2Update and Col3Update are true ....
....
So is dynamic SQL a good option for this case too?!

The trigger is going to be fired anyway, teh data engine is going to be invoked anyway, the update is going to be logged anyway, because col1 is alwys updated. So having the 2 case expressions in the update statement to generate updates that either do or don't update col2 and col3 doesn't generate any noticeable overhead, may even be cheaper in performance terms than building dynamic SQL.

Of course if you have an IF UPDATED(col2) condition in the trigger that wants to know whether col2 was actually changed you have to write it differently, but that is trivial for your update statement (and supertrivial if id is a unique key).

Tom

PiMané
PiMané
Mr or Mrs. 500
Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)Mr or Mrs. 500 (592 reputation)

Group: General Forum Members
Points: 592 Visits: 1334
Thanks,
Pedro



If you need to work better, try working less...
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45207 Visits: 39925
Sean Lange (10/2/2012)
It will work but referring to columns by ordinal position is fraught with maintenance issues.


Not to mention that (IIRC) it's been deprecated.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Sean Lange
Sean Lange
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16626 Visits: 17024
Jeff Moden (10/4/2012)
Sean Lange (10/2/2012)
It will work but referring to columns by ordinal position is fraught with maintenance issues.


Not to mention that (IIRC) it's been deprecated.


And something I have avoided like the plague long before it was deprecated.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
TomThomson
TomThomson
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10743 Visits: 12019
Sean Lange (10/4/2012)
Jeff Moden (10/4/2012)
Sean Lange (10/2/2012)
It will work but referring to columns by ordinal position is fraught with maintenance issues.


Not to mention that (IIRC) it's been deprecated.


And something I have avoided like the plague long before it was deprecated.

+1

Tom

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search