As discussed in previous posts, there are multiple ways to get access to data in SharePoint lists and other sources.
The primary goal for using large lists is to store content and then be able to retrieve it, nothing fancy. A good plan for how that data will be retrieved is important as it affects the overall performance of the large list. The success of that list also has to be looked at. There are many features to consider here including search, metadata navigation, Content Query Web Parts, and views. You also need to take a look at the custom solutions how they might come into play.
The use of a central landing page for your homepage is a good idea. This allows every entry points for your large list. The use of published pages to create a site and to have different topics on each page can be compiled. There are several things you can do with such a set up successfully implemented:
- Any combination for a search, list view, Content Query Web Parts, or metadata navigation can be used.
- Planning allows for the content to be retrieved easily. It also lets you know which of the columns will be used for filtering and sorting.
- The basic page model also needs to be planned. This allows for the work to be done to show up in the document library.
There are several features of SharePoint 2010 that can be allocated for a query and filter list to be configured. You can also access different options for the custom code in order to query the list. This includes:
- Views for configuring the columns that are displayed. This allows for the filtering and sorting of results based on columns.
- Content query Web Parts offers data from SharePoint lists. The queries can be configured for results from one or many lists. This will all be cached by default but you can disable this feature if it tickles your fancy.
- Search boxes can be used to result search results. Those results can also be used to create metadata refined controls and thus narrow down the search results even further.
The different query methods can be used in different ways, these will each have a dedicated post to it.
- List view & metadata navigation List views access the SQL server and that is why they are the most expensive queries. They also result in a higher SQL Server load. List views can provide you with more options for documents as well as real time access for the data.
- Content Query Web Part This uses the portal site map to cache queries. They also use the least amount of HTML and so the query is completed fast. This should be used when you have a dynamic type of navigation that has to be done. It can also be used when you have multiple queries on a single page.
- Content Query Web Part (non-cached) This provides real time access to data. The Content Query Web Part offers a query for the database. This configuration should be used when the query can’t be cached, you need real time updates, or the pages to be accessed are cached only once per hour. The loading of a cached Content Query Web Part can be expensive.
- Search This type of query allows for offload read to be send to infrastructure of the server. This is a simple way to scale and it allows for read performance to increase due to the optimization. Search queries can be configured so that you use static queries or so that particular users are able to use specific search queries.