SQLServer如何处理到达数据库引擎的查询





当一个查询到达数据库引擎时,SQL SERVER执行两个主要的步骤来产生期望的查询结果。第一步是查询编译,它生成查询计划,第二步执行这个查询计划。

 

SQL SERVER 2005中的查询编译由三个步骤组成:分析、代数化查询优化。完成这些步骤后,编译器把经过优化的查询计划保存到过程缓存中。在这里,执行引擎把该计划转换为可执行的形式,然后执行其中的步骤以生成查询结果。如果今后再次执行相同的查询或存储过程时,过程缓存已经包含了该计划,则跳过编译步骤,直接重用缓存的计划来执行该查询或存储过程。

 

关于SQL Server**的优化

SQL SERVER并不优化批处理中的每条语句。只优化那些访问表而且可能生成多个执行计划的语句。SQL SERVER优化所有DML(数据操作语言)语句,即SELECT DELECTUPDATE语句。除了DML,其他一些T-SQL语句也会被优化,CREATE INDEX便是其中之一,只有被优化过的语句才会生成查询计划。

 

关于SQL**中的分组

GROUP BYHAVING之类显式子句并不是使SELECT列表被分组的唯一因素。根据SQL的规定,只要出现绑定到特定列表的聚合函数,即使没有GROUP BYHAVING子句,也会使SELECT列表分组。下面是一个简单的示例:

SELECT c1,MAX(c2) FROM dbo.T1;

这是一个分组SELECT因为查询中包含了一个MAX聚合。又因为它是一个分组SELECT,在其中使用非聚集的列c1是不合法的,所以该查询不正确。



版权声明:本文为博主原创文章,未经博主允许不得转载。


SQLServer同时操作(all-in-once)特性



Select列表中创建的别名不能在Select子句之前执行的子句中使用。实际上,表达式别名甚至不能用于Select列表的其他表达式。该限制是由于SQL的另一个独有的特性,即同时操作(all-at-once operation)。例如,在下面这个Select列表中,计算表达式的逻辑顺序无关紧要,而且具有不确定性

Select c1+1 As e1,c2+1 As e2.

因此,不支持下面这个表达式:

Select c1+1 As e1,e1+1 As e2.

你只能在Select列表后面的步骤(Order By步骤)中使用列的别名。

 

理解:同时操作(all-at-once operation)

我们在大多数编程环境下,交换两个变量的值,通常会使用一个临时变量:

//假设有两个已赋值的int型变量ab

int temp;

temp=a;   a=b; b=temp;

当然只是通常的做法,你也可以运用逻辑运算符:

a = a ^ b;

b = b ^ a;

a = b ^ a;

或者:b = a + (a = b) * 0;

但,在SQL中交换列值可以使用下面的语句:

Update dbo.T1 Set c1=c2,c2=c1;

你应该假设所有操作同时发生,而事实上,在更新完成之前并不会修改表(可以理解为更新过程中表中的记录被锁定),而在计算出所有结果之后替换了现有表中的源数据

所以,下面的更新语句:

Update dbo.T1 Set c1=c1+(Select Max(c1) From dbo.T1);

该更新将影响T1表中的所有行,为C1列加上更新开始时T1中的最大的c1值。此时可以认为更新开始后表中的记录被锁住,数据库在后台处理、计算数据。计算完所有数据之后,将一次性替换所有数据。所以你不用担心最大的c1值会随着操作进行而持续变化,可以理解为操作在瞬间发生了。



版权声明:本文为博主原创文章,未经博主允许不得转载。


SQLServer执行逻辑查询时,SQL被解析的步骤



以下这段对SQL Server执行逻辑查询时,SQL被解析的步骤。摘自《SQL Server 2005技术内幕 T-SQL查询》。这是一本非常好的讲解SQL Server的书,整个SQL Server 2005技术内幕系列都是,个人强烈推荐。

 

我一直认为,学好任何一种技术,没有什么比学好它的基础知识和底层原理更重要。如果你相信有“捷径”,那么这就是唯一的“捷径”。了解这些,有助于你更快地掌握技术最本质的核心。

我真希望早点看到那些好书,也希望看到这篇文章的你,能有点收获,多读好书,少走一些弯路。

 

他山之石可以攻玉!

 



以上步骤从1-11按顺序被执行,如果没有将跳过相应步骤;

以上每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入。这些虚拟表仅用于查询器内部使用,对调用者或外部查询不可用,只有最后一步生成的表才会返回给调用者。

 

逻辑查询处理阶段:

1.       From:对From子句中的前两个表(left_tableright_table)执行笛卡尔积[交叉联结],生成虚拟表VT1.

2.       On:VT1应用On筛选器,只有那些使<join_condition>为真的行才被插入VT2

3.       Outer(Join):如果指定了OUTER Join(相对于Cross JoinInner Join),保留表中未找到匹配的行将作为外部行添加到VT2,生成T3。如果From子句包含两个以上的表,则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3,直到处理完所有的表为止。

4.       Where:对VT3应用WHERE筛选器,只有<where_condition>True的行才被插入VT4

5.       Group By:按Group By子句中的列列表对VT4中的行分组,生成VT5.

6.       CUBE|ROLLUP:把超组插入到VT5,生成VT6.

7.       Having:对VT6应用Having筛选器。只有<having_condition>true的组才会被插入VT7

8.       Select:处理select列表,产生VT8

9.       Distinct:将重复的行从VT8中移除,产生VT9.

10.   Order By:将VT9中的行按Order By子句中的列列表排序,生成一个游标(VT10)

11.   Top:从VC10的开始处选择指定数量或比例的行,生成表VT11,并返回给调用者。



版权声明:本文为博主原创文章,未经博主允许不得转载。


关于FormView在编辑模板下找不到控件的问题



今天写一支程序,其主要是一个GridView联合一个FormView去完成增改删查的功能,本来这是一个非常简单的问题。但由于需要,在FormView的编辑模板中采用两个隐藏控件绑定了两个字段。在GridView的模板列中直接点击修改,那么没有任何问题,但如果先点击详情,切换到FormView的ItemTemeplet中,在该模板中点击返回,回到GridView视图中。然后,再次点击修改时,问题就出现了,跟踪的时候找到的控件引用都为Null,找了很久都没找到原因。

Read More

C#检测外键冲突的代码



大家都明白,在设计数据库的时候,外键的存在无可避免。在带来好处的同时(确保数据的完整性和一致性等,这些都不多说了),也有它的很多缺陷,那就是使诸如查询等相关操作的效率降低(但有的时候这也是没办法的事情,现在硬件发展都这么快了),但最主要的是,某些时候,在用户不知道各个实体关系的情况下,他们想去删某些记录,下面我们举个例子。

Read More

OA系统权限管理设计(转载)



任何系统都离不开权限的管理,有一个好的权限管理模块,不仅使我们的系统操作自如,管理方便,也为系统添加亮点。

 

l        
不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。

l        
可以对进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。

l        
权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。

l        
满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。

 

针对OA系统的特点,权限说明:

 

权限

在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。

权限组

为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。

角色

权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。

用户组

将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。

 

通过给某个人赋予权限,有4种方式(参考飞思办公系统)

A.       
通过职位

a)        
在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。

 

b)       
实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。

 

B.       
通过项目


a)        
在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。

 

b)       
实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权和查看文档权即可。

 

c)       
对于组长,因为可以赋予组长一个组长权(组长权是个特殊的权限,它包含其他各种权限的一个权限包),所有组长对于本项目有全权,则项目组长可以对于项目文档查看,审批,删除,恢复等,这些权限对于本项目的下级项目依然有效。

 

C.      
通过角色


a)        
角色中的成员继承角色的权限,角色与角色没有上下级关系,他们是平行的。通过角色赋予权限,是指没办法按职位或项目的分类来赋予权限的另一种方式,如:系统管理员,资料备份员

 

b)       
实例中:对于本系统中,全体人员应该默认都有的模块,如我的邮件,我的文档,我的日志,我的考勤……,这些模块系统成员都应该有的,我们建立一个角色为系统默认角色,把所有默认访问的模块的浏览权加入到里面去,则系统成员都能访问这些模块。

 

D.      
直接指定


a)        
直接指定是通过对某个人具体指定一项权限,使其有使用这个权限的能力。直接指定是角色指定的一个简化版,为了是在建立像某个项目的组长这种角色时,省略创建角色这一个步骤,使角色不至于过多。

b)       
实例中:指定某个项目的组长,把组长权指定给某个人。

 

针对职位、项目组:

如果用添加新员工,员工调换职位、项目组,满足了员工会自动继承所在职位、项目组的权限,不需要重新分配权限的功能。

 

用户管理

用户可以属于某一个或多个用户组,可以通过对用户组授权,来对组中的所有用户进行权限的授予。一个用户可以属于多个项目组,或担任多个职位。

授权管理

将一个基本权限或角色授予用户或用户组,使用户或用户组拥有授予权限的字符串,如果角色、职位、项目中存在相同的基本权限,则取其中的一个;如脱离角色、职位、项目组,只是取消用户或用户组的中此角色、职位、项目组所授予的权限。用户所拥有的权限是所有途径授予权限的集合。管理员用户可以查看每个用户的最终权限列表。

权限管理

基本操作权限与权限组(基本操作权限的集合)的管理。

oa


 

 

物理数据模型图如下:

 

oa2

 

 

 

根据以上设计思想,权限管理总共需要以下基本表:

tb_User:用户信息基本表;

tb_Department:部门表;

tb_Company:公司表;

tb_Module:系统模块表;

tb_Action:系统中所有操作的动作表;

tb_Permit:由tb_Module与tb_Action两表结合产生的系统基本权限表;

tb_Permit_Group:权限组表,将一模块的中的所有权限划分一个权限组中,可以通过权限组授予用户权限;

tb_Role:角色表,基本权限的集合。无上级与下级之分;

tb_Position:职位表,有上级与下级之分;

tb_Project:项目组表,

tb_Role_Permit:角色授权表;

tb_Postion_Permit:职位授权表;

tb_Project_Permit:项目授权表;

tb_Project_User:项目成员表,IsLead字段代表此成员为项目组长;

tb_Postion_User:职位成员表;

tb_User_Permit:用户授权表,用户ID与角色、职位、项目及直接授予的权限串表;

权限的产生:

由tb_Module中的ModuleCode与tb_Action中的ActionCode组成

权限代码PermitCode=ModuleCode+ActionCode。

       实例:ModuleCode=0101,ActionCode=01,则PermitCode=010101。

       权限值则有ModuleValue与ActionCode组合而成,采用下划线来连接。

       实例:ModuleValue=Sys_User,ActionValue=AdD,PermitValue= Sys_User_Add

权限组:

       包括一组同一模块下的权限的组合,如管理用户包括基本的权限:添加、删除、修改、查看等,将这些组合起来构成一个用户组——“用户管理”权限组。其它类似。只是为了更方便的查看系统权限与权限的分配。

       实例:如管理用户的权限代码为010101à查看用户,010102à添加用户,010103à删除用户,010104à修改用户,010105à审核用户等,将这些基本权限组合起来一个集合而构成了“用户管理”权限组。

角色、职位、项目:

       也就是按特定的需要划分一种权限的集合。使用角色授权表、职位授权表、项目授权表来实现。授权表中存放的是权限代码PermitCode,而不是权限组的GroupCode代码。

用户授权:

       由用户授权表来实现,用户授权表中的RoleCode、PositionCode、ProjectCode分别是角色表中RoleCode组成的串、职位表PositionCode组成的串、ProjectCode组成的串。与角色授权表中的角色代码RoleCode、职位授权表中PositionCode、项目授权表中的ProjectCode不对应(不是主表与从表之间外键关系)。

       从而能够实现了一个用户可以拥有多个角色、多个职位、多个项目的情况。

用户授权表中的PermitCode为直接授权的权限代码串,直接给用户分配权限。

实例:

用户ID为UserId=1的用户权限授权表的记录为:

RoleCode=001,003

PostionCode = 001,002

ProjectCode=001,005

PermitCode = 010101,020102

表明此用户拥有两个角色,代码为001和003,并继承这两个角色的权限;

担任两个职位,代码为001与002,并继承两个职位的权限;

属于两个项目组中的成员,项目代码为001与005,并继承两个项目中的权限。

直接指定给用户的权限为010101与010102这两个权限代码的权限

用户权限字符串:

    根据用户授权表的角色代码、职位代码、项目代码得到权限字符串及表中直接分配的权限字符串组合成一个用户的所有权限字符串集合。