Friday, October 12, 2007

How Sharepoint Lists work internally?

For anyone who has worked with lists in Sharepoint will come to wonder - How does this work? On occasion I did notice some weak spots: i.e no referential integrity between two lists - unlike two separate tables with unique keys and foreign keys. Although a Sharepoint list is pretty powerful especially when one has to create a spreadsheet with a form all from the browser. Now, I have some understanding on how lists work - but may be not totally.
I understand that by looking at the database, a list comprise of two tables (can be found in the content db of a sharepoint site):


1) the dbo.Lists table, and 2) the dbo.UserData table. Each time a list is created, an entry goes on the dbo.Lists table along with the necessary info (unique id, list title, created by, date and other metadata). Included in this entry is a "field" that defines the Columns inside that list - this is in the "tp_Fields" field. An screenshot of this is shown below:



From this single entry in the dbo.Lists table defines the makeup of a list.
Now the tricky part comes in the dbo.UserData table - where the user entries are entered. The table consists of over a hundred columns. A screenshot of the fields for this table is shown below:


Every time a user enters a data into a list, the stored procedure picks up: the list id, site id, user info, time stamp AND THEN plug in the rest of the data onto the proper column corresponding to the right datatype the list creator dictated from the initial creation of the list - columns whether it be nvarchar, float, datime etc.

Figuring out how this is done somewhere within the tp_fields column and the stored procedure is one ambitious task. Anyone have some explanation to this feel free to post. Thank you

No comments: