从算法入手讲解SQL Server的典型示例
Server数据库中实现最优最简的整个过程。
算法是计算机科学中一个重要的研究方向，是解决复杂问题的关键。在计算机世界中，算法无处不在。数据库是存储数据和执行大批量计算的场所，在数据库中使用一些简单的SQL命令，进行存储、查询、统计、以解决现实世界中的问题已经是屡见不鲜。随着数据量的大幅度增加和业务规则的日益复杂，越来越需要一种专门的方法来满足效率和准确性方面的要求。如何把解决问题的复杂算法转换为数据库能够执行的命令，也是数据库应用技术研究的一个方面。本文以MSSQL中的命令来阐述例子。
数据库中可以存储实体的数据集合，在进行运算时，数据库使用批量计算的方法来处理数据，批量的从存储设备上读取数据，处理之后又批量的写回存储设备。有的数据库提供了游标，游标可以读取出表中一行的数据中的每一个字段，对这些字段进行复杂的业务规则计算，然后再写回数据库中。与使用批量的方法比较，批量计算的方法消耗的资源相对比较少，而使用游标则占用太多的资源，速度比较慢，效率较低并且还有加锁条件等许多的限制。
比如对于数据库中存储了学生成绩student_Score(sno,cno,score,level)，成绩从0分到100分不等，如果需要在分数的后面存储一个字段字level来说明成绩的优劣，90分以上的A，80-90分为B，60-80分的为C，60分以下的为D，以下有几种算法都可以达到同样的目标：
1.定义一个游标，选择student_Score表中所有的成绩记录，定义一个存储成绩的变量@cur_score，存储当前纪录的分数，定义一个存储当前分数所在成绩级别的变量@cur_level，用以存储成绩好坏的标记。算法如下：如果游标中的纪录不为空，从游标中取出当前纪录的成绩，判断成绩所在的分数段，把结果存储在变量@cur_level中，以@cur_level中的值更新当前纪录中的level字段。整个过程需要至少读取数据库两次，一次为获得纪录，一次需要写入数据库，每条记录都需要经过这个过程，效率相对低。
2.依次批量更新数据库，把所有的level字段的值设置为D，再次更新数据库，把成绩大于等于60的纪录的Level字段更新为C，依次更新B、A。这样做的一个缺点是有些纪录的Level字段被更新多次，比如一个记录最后的Level字段的值是A，则它首先被更新为D，依次被更新为C、B、A。这些重复的更新是可以被消除的，把算法改进一下就可以省去重复更新的花费。更新后的算法是这样的，把成绩介于0和60分的纪录的Level字段更新为D，依次更新各个分数段的成绩。实现的这种算法
相关文档：
调用 MS SQL 标量值函数，应该在函数前面加上 "dbo."，否则会报 “不是可以识别的 内置函数名称”错误。例如
DECLARE @WhichDB TINYINT;
SELECT @WhichDB = user_GetWhichDB(1);--看看是哪个数据库的
=================================================
-- ......
感谢提康德罗加的投递
就像当年波士顿的爱国者为反抗英国重税的行动一样，NoSQL的支持者们从各地涌来，分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据，他们开始对SQL说不！NoSQL组织上个月在旧金山的行动让人闻到了数据库革命的味道，好像一个现代IT业版的波 ......
CREATE procedure SqlPager_Ex
@sqlstr varchar(8000), --查询字符串
@currentpage int, --第N页
@pagesize int --每页行数,
as
set nocount on
declare @P1 int, --P1是游标的id
@rowcount int
exec sp_cursorope ......
第一种方法: 使用output参数
USE AdventureWorks;
GO
IF OBJECT_ID ( 'Production.usp_GetList', 'P' ) IS NOT NULL
DROP PROCEDURE Production.usp_GetList;
GO
CREATE PROCEDURE Production.usp_GetList @product varchar(40)
, @maxprice money
&nb ......
日前SQL INJECTION的攻击测试愈演愈烈，很多大型的网站和论坛都相继被注入。这些网站一般使用的多为SQL SERVER数据库，正因为如此，很多人开始怀疑SQL SERVER的安全性。其实SQL SERVER 2000已经通过了美国政府的C2级安全认证-这是该行业所能拥有的最高认证级别，所以使用SQL SERVER还是相当的安全的。当然和ORCAL、DB2� ......
