大家都知道，Sharepoint的列表实际上是对数据库中表(Table)的概念的延伸。但是当我们打开Sharepoint的时候，会发现，你建立的列表并没有存储成数据库中的一张表。那么列表是存储在哪里的呢？他们在运行中又是怎么被提取出来的呢？从这篇文章开始，我们要一点一点将MOSS的神秘的存储结构剖析清楚，不仅仅对MOSS的开发有帮助，也可以拓宽我们的软件体系设计的思维。

  打开SqlServer 中对应的数据库，我们会发现有很多很多的表存在，其中最为重要的当属dbo.AllUserData表。里边存储了基本上所有的数据。当然，你存储在列表中的数据也是存储在这里的。
  打开这个表，你会发现有很多的列。在后边就会知道这些列都是用来做什么的。
 

   其实，MOSS的列表概念可以理解成一张虚表，它并不是真实存在的，而是在需要的时候，从AllUserData中动态的提取出来，不过AllUserData存储的是所有的数据，像被丢在回收站的数据也是在里边被保留下来的，只不过被做了一个特殊的标记。

聪明的读者一定发现了，AllUserData中的tp_ListId就是确定不同的“虚表”的，如果写成sql查询，应该类似于这样

是的，这样就可以简单的将自己需要的数据单独提取出来了。不过这只是第一步。最重要的是，列表中的列，在AllUserData中怎么表示呢？反正不能新建一个列，就改动AllUserData的结构吧。并且怎么处理不同列的相同列名的情况呢（比如内容类型）？聪明的MS开发者使用的是这么一种办法。在AllUserData表中，预先留置了很多很多的，多到你用不完的数据列，这些列的列名就是他们的类型+编号。比如nvarchar1,nvarchar2,float1,int3,datatime1......在MOSS中创建栏的时候，MOSS根据栏的类型，就会将数据存储到相应的这些数据列中。比如用户姓名会存入nvarchar1中，而年龄也许会存入int1中，这些存储不是随机的，而是采用的先到先服务(FIFS)的思想的。并且这些列与列名的映射都会存入dbo.AllLists表中的tp_Fields属性中。你可以在这个属性中看到映射。如果你稍微处理一下，这个属性中的数据可以按照XML文件来处理(后边会给出代码)。

好了，这个就是MOSS数据库的结构。有人会问，既然MOSS给了这么好用的List的概念，为什么还用煞费苦心的自己来读取数据呢？我想首先一个是更加了解MOSS体系结构，另外一个绕过了MOSS的一些体系上的效率问题，直接存取数据库的效率和灵活性，sql查询的强大，列表和列表自带的CAML查询应该是做不到的。

文章来源:http://www.windwhisper.cn/default.asp?id=32