When considering data access approaches in SharePoint 2010, it is important to also consider the role that search will play. Search queries are able to scale better than when you directly access SQL Server resources. This is due to the fact that such a search is optimized for high-read scenarios. It is simpler for it to scale out multiple search index and query servers when compared to scaling SQL Server needs. Search queries are less bothered by list size than Content Query Web Parts or list view queries. The Search Web Parts allow offloading queries from SQL Servers for scaling searches while the query and index servers are scalable and perform better. The results are determined by the full text search of the documents and a summary of text offers more information than those from other Web Parts. The problem is that results are only as current as the last crawl, no column values are displayed, and being unable to perform list actions.
Search offers you the best overall performance at various high scale points. The search shouldn’t be used if list actions have to be offered on item. It also won’t work if the data has to be offered in real time. This is because the results will only be as current as the last crawl. There are several WebParts that structure the aggregate search system:
- Core Results Web Part Complete results with the paging and the full featured Web Part. It can also handle specific queries based on the user or the system.
- Federated Results Web Part Small sets of results will be offered with a link that is optional. This is to allow for viewing of the full results.
- Search Box Web Part The Web Part is used to accept the input from the user for a query.