设计SQLServer里审计数据表.docVIP

　　设计SQL Server里审计数据表教育资源库 　　问题： 　　我所在的公司为了方便进行审计活动，想要在SQL Server数据库里添加保存关键表和列的历史数据的功能。我查阅了最近网站上与触发器相关的一些文章，如果使用触发器或者其他类似的技术，怎么样才能最好地保存历史数据呢?有什么可供选择的方法?确实有很多可以选择的方法吗?历史数据应该与源数据保存在同一个数据库里吗?这样做有有什么用处? 　　专家解答： 　　开始考虑保存历史数据是不错的想法。这样你可以有机会建立一个全公司各个应用程序都可适用的方案。不过你需要明白，要开发这样一个方案，需要投入大量的时间进行方案的计划、开发、测试和实施。如果你同意这么做，那么你需要把它作为一个项目看待，需要进行正式的项目开发程序，因为你的决定会对你们公司的程序和业务流程都有很大范围的影响。 　　要求 　　如果你同意保存审计数据作为一个项目进行，那么现在应该开始确定这个项目的一些要求。收集以下信息是开始这个项目的基本要求： 　　1.什么样的数据需要被审计 　　2.为什么要审计这些数据的原因 　　3.这些数据将会被如何使用 　　制作报表或用于商业智能 　　为了客服目的而需要记录信息修改历史 　　法律需要 　　4.哪些数据库和应用程序需要进行审计 　　5.什么类型的源数据需要跟审计数据保存在一起 　　开始日期 　　结束日期 　　开始日期和结束日期 　　记录保存的日期 　　用户修改信息 　　应用的程序，对应的数据库、SQL Server实例等 　　6.制作报表的需要 　　业务报表 　　月报表 　　业务流程报表 　　报告频率 　　报告用户 　　业务应用可否读取审计数据 　　7.收集数据 　　确定是否需要使用触发器、OUTPUT从句、存储过程逻辑、应用逻辑、Service Broker或者这些方法的结合使用来把数据写入审计表里。 　　8.数据一致性要求 　　考虑这些数据的使用方式，确定是否所有的审计数据需要以相同的格式存储。 　　9.审计数据存储位置 　　与基础数据一起存储，即存储在同一个数据库里或者是存储在不同磁盘系统的独立文件组里 　　存储在实例的某个特定数据库里，即不同的数据库里 　　存储在集中化的SQL Server数据库里，即远程实例中 　　方案设计的选择 　　就像刚才所说的，一些关键技术设计决定是关于数据要如何写入审计表里、审计数据存储在哪里、是否可以使用统一的方法来存储数据用于制作报表等等。对于这些问题，不同的答案需要开发不同的方案，我们下面可以简单介绍几种不同的方案，看看有没有适用于你的情况的： 　　复制基本表 　　这个方法是比较传统的审计技巧，针对每一个需要审计的基本表都创建一个审计表。基本表和审计表的设计很相似，只是审计表增加了一些列来管理历史数据(即AuditID列作为识别列，ModifiedBy列用于记录谁对记录做出过修改，等等)。我们下面用SQL Server 2005数据库中的一个AdventureodifiedDate][datetime]NOTNULLCONSTRAINT[DF_EmployeePayHistory_Audit_ModifiedDate]DEFAULT(getdate()), 　　[ModifiedBy][varchar](100)NOTNULLCONSTRAINT[DF_EmployeePayHistory_Audit_ModifiedBy]DEFAULT(SUSER_SNAME()) 　　CONSTRAINT[PK_EmployeePayHistory_Audit_AuditID]PRIMARYKEYCLUSTERED 　　( 　　[AuditID]ASC 　　)ARY] 　　)ON[PRIMARY] 　　GO 　　通用的查找表 　　实现审计目的的另一种方法就是利用通用表来存储所需的数据，结合一个查找表来识别审计数据的原来所在列。这种方法设计的优点在于每一个基础表可以使用统一的设计，然后扩展查找表来添加新列，这样制作的报表也可以保持一致性。另外，这个设计还可以进一步扩展，用于单个数据库、实例、应用程序或者整个数据环境，只需要添加一些额外的列和所需的基础设施而已。 　　下面是SQL Server 2005 AdventureodifiedDate][datetime]NOTNULLCONSTRAINT[DF_EmployeePayHistory_Audit_Generic_ModifiedDate]DEFAULT(getdate()), 　 12下一页 这篇文章来自..，。[ModifiedBy][varchar](100)NOTNULLCONSTR