<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
0pt0pt 0.8ex; padding-left: 1ex;"><div class="im"><br /><br /><blockquote class="gmail_quote" style="border-left: 1px
solidrgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Similarly using the no. of select hits on a
tablewe can check that if maximum no. of times it is on a non-index field we can index on that field to make select
faster.<br/></blockquote><br /></div> It's impractical to figure out where indexes should go at without simulating what
theoptimizer would then do with them against a sample set of queries. You can't do anything useful just with basic
statisticsabout the tables.<br /><br /> I would recommend <a
href="http://msdn.microsoft.com/en-us/library/aa226167%28SQL.70%29.aspx"
target="_blank">http://msdn.microsoft.com/en-us/library/aa226167(SQL.70).aspx</a>as a good, practical introduction to
thetopic of what it takes to figure out where indexes go at, from someone who came up with a reasonable solution to
thatproblem. You can find a list of the underlying research they cite (and an idea what has been done since then) at
<ahref="http://portal.acm.org/citation.cfm?id=673646"
target="_blank">http://portal.acm.org/citation.cfm?id=673646</a><divclass="im"><br /></div></blockquote></div><br
/>Evenif you have devised a way to find the appropriate set of indexes, just have a index adviser, which would advise a
setof indexes for a set of queries and let the DBA and the application user take the final call, after looking at
them..<br/><br />Gokul.<br />