ws11
asked on
Indexing Tables to Handle Column Sorts
What is the proper way to handle large queries when column sorts are an option in a web application interface? These queries have several joins. The user has options to custom create reports by picking the columns the report requires so there is the potential for a column count of 20 or more as well. Data in the tables frequently change from insertions, edits or deletes.
ASKER
Indexing every field does not make sense to me. That is one of the reasons I am asking this question. What is the most efficent way of doing this. I also wonder what the difference is in creating views for this with indexes. Since the data is constantly be edited it is my understanding that you don't use indexed views. But what is the difference in that and the index table that are constantly edited.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
if you are curious for what is costing time/cpu then investigate: start Activity Monitor for the the server (in SQL Server Management Studio), look at "recent Expensive Queries", right click an interesting query (for the actual database) and click "show Execution Plan" - and see details, eventuallm play with cost with and without indexing :-)