SharePoint lists consist of records that are stored in a SQL Server database and managed by SharePoint - the alternative to using list is to write to a custom database.  

A key decision that needs to be made when architecting a SharePoint solution is whether to store data in a list or a database; the following is important to know when considering storage requirements:

Benefits of lists follows:

• SharePoint Web parts provide simple methods for managing the data
• Workflow/event handlers can easily be registered to them.

Disadvantages:

• Cannot be used if business logic requires transactions
• Cannot store complex data models with intricate relationships
• Limit of 2,000 items for each list container (recommendation by SharePoint Product team)

The following link references a white paper regarding "Working with Large Lists in Office SharePoint Server 2007"
http://blogs.msdn.com/sharepoint/archive/2007/07/25/scaling-large-lists.aspx

An excerpt from the above link follows:

There is documented guidance for Microsoft® Office SharePoint® Server 2007 regarding the maximum size of lists and list containers. For typical customer scenarios in which the standard Office SharePoint Server 2007 browser-based user interface is used, the recommendation is that a single list should not have more than 2,000 items per list container. A container in this case means the root of the list, as well as any folders in the list — a folder is a container because other list items are stored within it. A folder can contain items from the list as well as other folders, and each subfolder can contain more of each, and so on. For example, that means that you could have a list with 1,990 items in the root of the site, 10 folders that each contain 2,000 items, and so on. The maximum number of items supported in a list with recursive folders is 5 million items.

White Paper available in above link: SharePoint-LargeList.doc (619.50 kb)

The Baseline test  

Milliseconds to seconds Calculator 

An excerpt from the white paper followsThe goal for the next set of tests was to establish our baseline numbers. Here are the results of the different data access methods against a list with 1,500 items. Only the most common data access methods were included in the baseline testing, so test results for the PortalSiteMapProvider class were not included.

What stands out clearly in this set of results is that viewing the data using the predefined Office SharePoint Server 2007 browser interface is the slowest data access method by far. This is one of the reasons why guidance has been delivered to restrict list sizes to no more than 2,000 items per container. It’s also why we recommend that you don’t consider going above the 2,000 items per container unless you are developing an alternative interface to work with the data.

Deletes can range from 30 to 80 seconds:

More statistics available in white paper

Tags: sharepoint, performance
Categories: