揪出ASP.NET 2.0四大“插件”的总后台 -- ASPNETDB
数据库关系图、表和视图(1) 基本表和独立表
ASPNETDB 这个隐藏在ASP.NET 2.0四大“插件”
(
SqlMembershipProvider、
SqlRoleProvider、
SqlProfileProvider、
SqlPersonalizationProvider
)
之后,时不时在你App_Data目录下幽灵般出现的SQL数据库,其实也并没什么神奇之处,
我等凡夫俗子进去一看,原来也不过如此。不过如果我们要编写自定义Provider的话,
还是得仔细研究一下下的,因为这4个Provider大部分的业务逻辑还是“封装”在这个数据库里的。
下面,就容我这个老小弟,为各位兄弟理出里面的表、视图和存储过程。
注:其实还有SqlWebEventProvider,它用到表aspnet_WebEvent_Events和存储过程aspnet_WebEvent_LogEvent。
因为老小弟认为从性能上考虑,写入本地文件是更好的选择,所以在此不作介绍。
另外,还有个和ASPNETDB无关的 SiteMapProvider,主要配合SiteMapPath 等控件,一般以Xml文件形式存放站点地图。
看张“地图”先:
数据库关系图、表和视图(1) 基本表和独立表
ASPNETDB 这个隐藏在ASP.NET 2.0四大“插件”
(
SqlMembershipProvider、
SqlRoleProvider、
SqlProfileProvider、
SqlPersonalizationProvider
)
之后,时不时在你App_Data目录下幽灵般出现的SQL数据库,其实也并没什么神奇之处,
我等凡夫俗子进去一看,原来也不过如此。不过如果我们要编写自定义Provider的话,
还是得仔细研究一下下的,因为这4个Provider大部分的业务逻辑还是“封装”在这个数据库里的。
下面,就容我这个老小弟,为各位兄弟理出里面的表、视图和存储过程。
注:其实还有SqlWebEventProvider,它用到表aspnet_WebEvent_Events和存储过程aspnet_WebEvent_LogEvent。
因为老小弟认为从性能上考虑,写入本地文件是更好的选择,所以在此不作介绍。
另外,还有个和ASPNETDB无关的 SiteMapProvider,主要配合SiteMapPath 等控件,一般以Xml文件形式存放站点地图。
看张“地图”先:
数据库关系图
![aspnetdb Diagram](/images/cnblogs_com/windman/aspnetdb.gif)
这张图还是蛮重要的,兄弟们在看后面的内容时,还是要常回来看看,回来看看。
表
在ASPNETDB数据库的几个表中,都有名称为Lowered***的字段,
这些字段用来存放***字符串字段的小写形式副本。
因为这些***字符串字段的比较都是不区分大小写,在表中存放一个小写形式副本,
能提高字符串比较的速度。
基本表 aspnet_Application、aspnet_Users
在ASPNETDB数据库的几个表中,都有名称为Lowered***的字段,
这些字段用来存放***字符串字段的小写形式副本。
因为这些***字符串字段的比较都是不区分大小写,在表中存放一个小写形式副本,
能提高字符串比较的速度。
基本表 aspnet_Application、aspnet_Users
-
应用程序表
每个Provider都有一个ApplicationName属性,该属性一般定义在web.config中。
举一个ProfileProvider的例子(其余3个Provider也一样):
<system.web>
...
<connectionStrings>
<add name="SqlSrvConnectionString" connectionString="..."/>
</connectionStrings>
...
<profile defaultProvider="SqlSrvProfileProvider">
<providers>
<add name="SqlSrvProfileProvider"
type="System.Web.Security.SqlProfileProvider"
connectionStringName="SqlSrvConnectionString"
applicationName="WebShop"
commandTimeout="30"
description="SqlSrvProfileProvider" />
</providers>
<properties>
...
</properties>
</profile>
...
</system.web>
这样你就为你的应用程序注册了一个"WebShop"名称
(也可以不明确配置applicationName值,默认为应用程序的虚拟根路径,即"/")。
要注意的是如果你那天把"WebShop"改成了"WebShop1"
(改成"webshop"、"webShop"等就和没改一样,因为应用程序名称是不区分大小写的),
你以前的用户自定义属性值就人间蒸发了,因为ProfileProvider把"WebShop1"
当作一个新的应用程序又新注册了一遍(这时候看过我这篇文章的兄弟
就该知道怎么办了,哈哈)。
那4个Provider是否一定要配置成同样的applicationName呢?当然不必要啦!
你为每个Provider各建一个数据库都没有关系,何况区区applicationName值呢。
不过在此老小弟建议各位兄弟,别没事找事,还是取一样的名称好。
-
基本用户表
表中MobileAlias字段(以及用户成员资格表aspnet_MemberShip中的MobilePIN字段),
没见在那里用到。老小弟猜想微软这样做有两种可能:一种是想以后帐户和手机绑定,
另一种可能就是为手机上网而预留的。
不知各位DBA兄弟有没看出这个表与它的几个从表的关系,有点不太“讲道理”,
居然有2个一对一的关系。“为什么不合并?不知道第3范式啊?”,老小弟
以前想装文化人的时候,总是这样吓唬小小弟的。若干年后,当老小弟看了几本
架构/模式的书,自我扫盲之后,才知道其实这是ORM模式中的一种。
另外,微软工程师这样设计还是非常巧妙的。在将公有部分提成几张基本表后,
数据库关系图4个部分就可合可分了。你可以试着在数据库关系图盖掉某几个部分,
剩下的部分仍然能够成一个完整的系统。
最后再交待一下IsAnonymous和LastActivityDate两个字段。
因为个性化用户配置和页面个性化设置能够支持匿名用户,所以该表中也会存在匿名用户,
IsAnonymous字段就是指示用户是否为匿名用户的标志字段。
LastActivityDate字段记录用户最后活动时间。该字段十分重要,每次成功的操作都会更新它,
同时它也是判断用户是否为非活动用户的依据之一。很多存储过程都会用到它。
在分块描述4大部分之前,先容我简单地介绍一下两个独立的表:
aspnet_WebEvent_Events表:记录数据操作的事件日志(可由SqlWebEventProvider启用)。
aspnet_SchemaVersions表:
把它的内容贴出来,各位一看就知道了。原来是微软为数据库中的各个部分设置的版本号。
aspnet_WebEvent_Events表:记录数据操作的事件日志(可由SqlWebEventProvider启用)。
aspnet_SchemaVersions表:
![aspnetdb Diagram](/images/cnblogs_com/windman/SchemaVersions.gif)