在tpch数据库中创建一个u01用户,并设置默认架构为s01,这个架构可以晚于用户创建,并授予用户u01,tpch数据库的ALL权限:
2> go
1> CREATE USER u01 FOR LOGIN l01
2> WITH DEFAULT_SCHEMA = s01;
3> GO
1> grant all to u01;
2> go
ALL 权限已不再推荐使用,并且只保留用于兼容性目的。它并不表示对实体定义了 ALL 权限。
在tpch数据库中创建一个s01架构,并指定架构拥有这是u01用户,以u01用户创建的表自动属于s01架构。
2> go
1> EXECUTE AS user = 'u01'
2> go
1> create table t (a int not null);
2> go
1> select * from t;
2> go
a
-----------
(0 行受影响)
1> select * from tpch.s01.t;
2> go
a
-----------
(0 行受影响)
用sa用户访问,可以区别dbo架构和s01架构下的同名t表是不同的对象。
2> go
1> select * from tpch.dbo.t;
2> go
c c1 c2
---------- ----------- ----------
1 2 3
2 21 31
3 31 91
(3 行受影响)
1> select * from tpch.s01.t;
2> go
a
-----------
(0 行受影响)
用登录名l01登录数据库服务器,并打开tpch数据库,可以直接进入s01默认架构。
密码:
1> SELECT SUSER_NAME() --显示登录名
2> go
------------------------
l01
1> SELECT USER_NAME() --当前为默认master数据库,不存在对应的用户名,显示为guest用户
2> go
----------------------
guest
1> SELECT schema_NAME()
2> go
----------------------
guest
1> use tpch
2> go
1> SELECT USER_NAME() --当前为tpch数据库,存在对应的用户名u01
2> go
----------------------
u01
1> SELECT schema_NAME()--当前为tpch数据库,存在用户名u01对应的架构s01
2> go
----------------------
s01
1> use tpch
2> go
1> select * from t;
2> go
a
-----------
(0 行受影响)
(5)聚集索引和非聚集索引
聚集索引,也可以理解为排序索引,就是说表中的数据存储位置,根据索引的排序进行实际存储,因此效率是相当高的。因为聚集索引决定了表中数据行的存储位置,所以,一个表不可能有两个或以上的聚集索引。因此,如果一个表中已经有一个聚集索引,那么这个表中其他的索引都将是非聚集索引。SQL Server的聚集索引和Oracle的索引组织表类似。
聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后,便可以确保包含后续索引值的行在物理相邻。例如,如果应用程序执行的一个查询经常检索某一日期范围内的记录,则使用聚集索引可以迅速找到包含开始日期的行,然后检索表中所有相邻的行,直到到达结束日期。这样有助于提高此类查询的性能。同样,如果对从表中检索的数据进行排序时经常要用到某一列,则可以将该表在该列上聚集(物理排序),避免每次查询该列时都进行排序,从而节省成本。
非聚集索引与其他数据库中的索引类似。数据存储在一个地方,索引存储在另一个地方,索引带有指针指向数据的存储位置。索引中的项目按索引键值的顺序存储,而表中的信息按另一种顺序存储(这可以由聚集索引规定)。如果在表中未创建聚集索引,则无法保证这些行具有任何特定的顺序。
SQL Server在搜索数据值时,先对非聚集索引进行搜索,找到数据值在表中的位置,然后从该位置直接检索数据。这使非聚集索引成为精确匹配查询的非常好的方法,因为索引包含描述查询所搜索的数据值在表中的精确位置的条目。如果基础表使用聚集索引排序,则该位置为聚集键值;否则,该位置为包含行的文件号、页号和槽号的行ID(RID)。例如,对于在列C上有非聚集索引的表,如要搜索其列C='a'的行,SQL Server会在索引中查找这样一个条目,该条目精确列出匹配的列C在表中的页和行,然后直接转到该页该行。