Best Practices For Accessing And Retrieving Data in SharePoint 2010 – Part 3 – Search WebParts

Company | Articles & Research | Services | Software |

Our Company

All SharePoint Articles

Security

Development

Accounting / Dynamics

AIS / Dynamics GP

Other

Consulting Services

Freeware / Experiments

Applications	WebParts	Security Components
SharePoint Field Diff And Copy Utility * Written In January, 2012 SharePoint Security Scanner * Written In January, 2012 SharePoint Kerberos Buddy * Written In Feburary, 2011 BioPoint: SharePoint Biometric Authentication * Written In September, 2007 SharePoint List Security Migrator * Written In August, 2007 SharePoint Anti-Keylogger™ * Written In April, 2006 S.M.A.R.T SharePoint™ * Written In May, 2006 SharePoint Sentinel™ * Written In June, 2006 SharePoint Scrubber™ * Written In July, 2006 SharePoint Safeguard™ * Written In August, 2006	SecureSilverlight For SharePoint * Written In January, 2010 Simple Rollup WebPart For SharePoint * Written In Novemember, 2009 SimpleChart For SharePoint * Written In December, 2009 SimpleSecurity For SharePoint * Written In June, 2009 CrytoCollaboration (Encryption) * Written In June, 2007 Sample AJAX Rotator WebPart * Written In July, 2007 Sample SharePoint Redirector WebPart * Written In August, 2006 WFE Server Name WebPart * Written In January, 2006	PDF IRM Protector * Written In December, 2010 ADAM Role Provider * Written In February, 2007 Universal Provider Framework * Written In April, 2007

Contact

Best Practices For Accessing And Retrieving Data in SharePoint 2010 – Part 3 – Search WebParts

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.