Sharepoint 2010 : Data Access Overview - Lists and Document Libraries

Lists and document libraries don’t physically exist. There is a perception that data stored in lists and libraries is slow to use because it exists in a file structure as opposed to a relational database, but this is not the case. All content managed by SharePoint lives in a relational database. Having said that, the highly abstracted nature of the data structure doesn’t lend itself to high performance data access, and as you’ll see later, there are other means of achieving this goal if it’s critical to your application design. Behind the scenes, all user data is actually stored in a single table in the content database.

SharePoint offers two types of content containers: lists and document libraries. The difference between these two is in the types of content that they can contain. Lists can contain only content that is not derived from the document content type, and document libraries can contain only content that is derived from the document content type.

From an object model perspective, a document library is a specialized form of a list. This is an important point, because the SPList object and its properties are the starting point for much of the custom code that we’ll write for the SharePoint platform.

This class diagram highlights an interesting point that we haven’t discussed so far: how columns and content types are related to lists and document libraries. You’ve seen how a content type can contain references to reusable columns, and you should understand how these content types can be used by lists and libraries to define the types of content that may be stored. However, from the class diagram, you can see that the SPList class has a Fields collection as well as a ContentTypes collection. From the diagram, you can also see that the SPWeb object has a Fields collection and a ContentTypes collection.

When we create content types or add new columns using the user interface, these columns are defined at the site level (which the object model confusingly represents using the SPWeb object). These columns are known as site columns and we can see this terminology used in the user interface and throughout the documentation. The same is also true for content types: when we create them using the user interface, they are known as site content types.

If we assign a content type to a list or library, SharePoint behind the scenes creates a new content type that inherits from our Site content type. This new content type is known as a List content type. Generally speaking, the ContentTypes collection of the SPList object will contain List content types. List content types and list columns can be freely changed at the list or document library level without affecting other instances of the associated site content type or column that are in use elsewhere.

As mentioned, columns exist independently of content types. A content type simply references the columns that it uses. As a result of this, when multiple content types are added to a list or library, the Fields collection of the associated SPList object contains an amalgamation of all the fields that are required. However, as well as the fields that are required by associated list content types, you can also add arbitrary fields to a list that are not associated with any content type.

Views

As we’ve seen from the class diagram, the SPList object has a collection of SPView objects. This raises the question, What is an SPView and how does it relate to lists and libraries? An SPView object represents the definition of a view on data contained within an SPList. In much the same way as an SQL view is ultimately an SQL statement that specifies the columns to select and any filters or sorting conditions, an SPView represents a query that selects values to be displayed from a SharePoint list together with any additional formatting parameters.

Queries

Data contained within SharePoint lists and libraries can be queried in a few ways.

Fundamentally, the SharePoint platform provides its own query language in the form of Collaborative Application Markup Language (CAML). As mentioned, one of the design goals of SharePoint was to create a platform that allowed nontechnical users to define data structures easily. As a consequence of this requirement, the underlying database schema does not lend itself to executing user-generated SQL queries. In fact, direct access to the underlying database is strongly discouraged and is not supported by Microsoft. Since executing standard SQL statements is not an option, Microsoft introduced CAML as a SharePoint-specific query language. Behind the scenes, the SharePoint platform converts CAML queries into valid SQL that extracts the required data from the underlying database schema, hiding the complexity of the schema from users.

Here’s an example of a CAML query:

<Query>
   <Where>
      <And>
         <Contains>
            <FieldRef Name='Title' />
            <Value Type='Text'>abc</Value>
         </Contains>
         <Lt>
            <FieldRef Name='FileSizeDisplay' />
            <Value Type=‘Computed’>50</Value>
         </Lt>
      </And>
   </Where>
   <OrderBy>
      <FieldRef Name=‘Created’ Ascending='False' />
   </OrderBy>
</Query>