February 17, 2012 at 9:31 pm
SQL Kiwi (2/17/2012)
Cliff Jones (2/17/2012)
Interesting but I don't think I want my developers to discover the FORCESEEK hint.This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.
Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is
+ 100
February 17, 2012 at 9:53 pm
bitbucket-25253 (2/17/2012)
SQL Kiwi (2/17/2012)
Cliff Jones (2/17/2012)
Interesting but I don't think I want my developers to discover the FORCESEEK hint.This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.
Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is
+ 100
I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.
February 18, 2012 at 9:23 am
DBA_Dom (2/17/2012)
bitbucket-25253 (2/17/2012)
SQL Kiwi (2/17/2012)
Cliff Jones (2/17/2012)
Interesting but I don't think I want my developers to discover the FORCESEEK hint.This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.
Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is
+ 100
I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.
Actually I agree also, my post was a bit tongue in cheek. But with 50 developers sometimes bad practices get copied around like a virus before you have a chance to educate or remind. Code reviews would help if only we did them more than we currently do.
February 18, 2012 at 7:53 pm
Cliff Jones (2/18/2012)
DBA_Dom (2/17/2012)
bitbucket-25253 (2/17/2012)
SQL Kiwi (2/17/2012)
Cliff Jones (2/17/2012)
Interesting but I don't think I want my developers to discover the FORCESEEK hint.This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.
Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is
+ 100
I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.
Actually I agree also, my post was a bit tongue in cheek. But with 50 developers sometimes bad practices get copied around like a virus before you have a chance to educate or remind. Code reviews would help if only we did them more than we currently do.
I'm sure that making sure developers understand what features are available, where those features are most likely to be beneficial, what potential issues there are with these features, and how they should go about evaluating the pros and cons of using a feature in a situation where they are considering it is the only sensible way to go (this applies to any language, not just SQL dialects); if the time taken to educate developers about new features is sufficiently long that they may go and misuse them before the education happens, the thing to do is to fix the working system so that the education happens in a more timely fashion. Yes there need to be warnings about some features (but perhaps not as extreme as the labelling suggested in my earlier post 😀 - ) - in fact as DBA_Dom suggests developers have to be told that using hints to override the optimiser is a last resort, but a new query hint (which is what we have here) hardly needs new guidance since some query hints have been around for a long time and if the developers don't yet know that query hints are a last resort that little piece of education is more than a decade overdue so something is seriously wrong.
Tom
February 18, 2012 at 8:50 pm
L' Eomot Inversé (2/18/2012)
Cliff Jones (2/18/2012)
DBA_Dom (2/17/2012)
bitbucket-25253 (2/17/2012)
SQL Kiwi (2/17/2012)
Cliff Jones (2/17/2012)
Interesting but I don't think I want my developers to discover the FORCESEEK hint.This is completely the wrong approach, in my opinion. I prefer to work with developers to share knowledge rather than hoping they stay in the dark. The most successful places I have worked have all had a healthy relationship between DBAs and developers, with regular sessions for each team to share ideas and techniques. I find that working positively with developers produces benefits for everyone.
Bold set by this poster. Now most would say +1 but for what I would say to SQL Kiwi's post is
+ 100
I have to say that I am in total agreement. It is far more beneficial to give people knowledge than to keep it from them as long as you teach them to use it properly. Meaning that using hints as a last resort.
Actually I agree also, my post was a bit tongue in cheek. But with 50 developers sometimes bad practices get copied around like a virus before you have a chance to educate or remind. Code reviews would help if only we did them more than we currently do.
I'm sure that making sure developers understand what features are available, where those features are most likely to be beneficial, what potential issues there are with these features, and how they should go about evaluating the pros and cons of using a feature in a situation where they are considering it is the only sensible way to go (this applies to any language, not just SQL dialects); if the time taken to educate developers about new features is sufficiently long that they may go and misuse them before the education happens, the thing to do is to fix the working system so that the education happens in a more timely fashion. Yes there need to be warnings about some features (but perhaps not as extreme as the labelling suggested in my earlier post 😀 - ) - in fact as DBA_Dom suggests developers have to be told that using hints to override the optimiser is a last resort, but a new query hint (which is what we have here) hardly needs new guidance since some query hints have been around for a long time and if the developers don't yet know that query hints are a last resort that little piece of education is more than a decade overdue so something is seriously wrong.
Yes, I think you hit the nail on the head. I work at a very fast paced and very successful software company and I don’t think anyone in our organization would use a Query Hint without checking with me to be sure it was appropriate. When you are dealing with a large development team sometimes that is the level at which you have to train. You can spend a lot of time training 50 dot net programmers how to write SQL but only a percentage will listen and only a percentage will remember everything. Would I spend 10 minutes of valuable training time to discuss the FORCESEEK Hint? No. Would I spend 30 minutes showing them why they shouldn’t try to out-guess the Optimizer with query hints? Yes. So it is easy to say give everyone all the details but sometimes it just not that simple.
February 21, 2012 at 5:22 pm
A good question... Thank you.
February 22, 2012 at 11:55 am
Good question, though I answered wrong!:(
October 11, 2012 at 2:15 am
I heard a lot a word 'FORCESEEk' can anyone explain me what is this?
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
October 11, 2012 at 3:07 am
http://msdn.microsoft.com/en-us/library/bb510478%28v=sql.105%29.aspx
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 30, 2013 at 5:53 am
January 5, 2015 at 11:40 pm
Got it right by logical thinking 😉
Thanks & Best Regards,
Hany Helmy
SQL Server Database Consultant
June 9, 2015 at 1:50 pm
Hi,
Could use the forceseek table hint.
What do you think?
Viewing 12 posts - 46 through 56 (of 56 total)
You must be logged in to reply to this topic. Login to reply