MSSQL网页编程之SQL Server 开辟之 数据纪录拼接聚合

Cluster/NDB高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用server|数据在SQLServer2000中供应了一些聚合函数，比方SUM、AVG、COUNT、MAX和MIN函数。但是偶然候大概要对字符串型的数据举行拼接。比方，把先生的选课情形以逗号支解举行显现等等。这类需求与SQLServer供应的聚合具有统一本性质，都是底本多是多个纪录，按某一个字段经由汇总处置后酿成一笔记录。比方先生选课的数据视图（一般是会有先生表、课程表、先生选课表联系关系而成）中的数据以下：学号选择课程
050301数据库道理
050301操纵体系
050302数据库道理
050302数据布局
050303操纵体系
050303数据布局
050303面向工具程序计划而必要的数据多是以下的布局：学号选择课程
050301数据库道理,操纵体系
050302数据库道理,数据布局
050303操纵体系,数据布局,面向工具程序计划要完成这类功效，能够有两种选择，一种利用游标，另外一种办法是利用用户自界说函数。为了复杂，上面就创立一个StudentCourse表，该表包含学号和选择课程两个字段。利用游标来完成
declareC1cursorfor
selectStudentId,CourseNamefromStudentCourse
declare@StudentIdvarchar(10)
declare@CourseNamevarchar(50)
declare@Countint
ifobject_id(TmpTable)isnotnull
droptableTmpTable
createtableTmpTable(StudentIdvarchar(10),CourseNamevarchar(1024))
openC1
fetchnextfromC1into@StudentId,@CourseName
while@@FETCH_STATUS=0
begin
select@Count=count(*)fromTmpTablewhereStudentId=@StudentId
if@Count=0
insertintoTmpTableselect@StudentId,@CourseName
else
updateTmpTableSetCourseName=CourseName+,+@CourseNamewhereStudentId=@StudentId
fetchnextfromC1ino@StudentId,@CourseName
end
closeC1
deallocateC1
select*fromTmpTableorderbyStudentId
利用用户自界说函数来完成

createfunctionGetCourse(@StudentIdvarchar(10))
returnsvarchar(4000)
as
begin
declare@snvarchar(4000)
set@s=
select@s=@s+,+CourseNamefromStudentCourse
where@StudentId=StudentId
set@s=stuff(@s,1,1,)
return@s
endgoselectdistinctStudentId,dbo.GetCourse(StudentId)
from
(
select*fromStudentCourse
)TmpTable支持多线程，充分利用CPU资源

如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。

分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。

所以你总能得到相应的升级版本，来满足你的需求。

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

仓酷云

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

两个月啃那本sqlserver2005技术内部-存储引擎，花了几个月啃四本书

无法深入到数据库系统层面去了解和探究

然后最好有实践机会，能够把实践到的和实践结合起来，其实理论思考是个非常困扰和痛苦的事情

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。