利用sql命令查询视图中一切援用的基本表

因此我们看到，这些信息足够让我们对单个操作实现“逆操作”。之前有写过怎样使用sql查询视图中一切援用的表发明这个办法其实不能查出视图中一切的基本表，假如视图中有嵌套视图就会有成绩，由于目次视图sys.sql_dependencies其实不包括一切的援用实体。前面发明在sql2008及今后的版本中推出的sys.sql_expression_dependencies视图办理了这一成绩，以是从头写了段sql，用来查询视图中一切援用的基本表，包含嵌套视图中的基本表。这个有甚么感化呢，大家有大家的用途吧，我是用来估量和优化视图的效力的，假如视图中援用的基本表太多，是否是就会在必定水平上影响功能呢？

查询的sql语句以下：
declare@v_namevarchar(50)
set@v_name=v_view--必要查询的视图名

declare@t_temp_referencedtable
(
tnamevarchar(50),
ttypevarchar(10),
tlevelint
)

insertinto@t_temp_referenced(tname,ttype,tlevel)
selecta.referenced_entity_name,b.xtype,0from
(
selectdistinctreferenced_entity_namefromsys.sql_expression_dependencies
wherereferencing_id=object_id(@v_name)and[referenced_class]=1and[is_ambiguous]=0
)a
leftjoinsys.sysobjectsbona.referenced_entity_name=b.name

declare@namevarchar(50)
declare@levelint
set@level=0

while(selectcount(1)from@t_temp_referencedwherettype=Vandtlevel=@level)>0
begin
declareresultcursorlocalforselecttnamefrom@t_temp_referencedwherettype=Vandtlevel=@level
openresult
fetchnextfromresultinto@name
while@@fetch_status=0
begin
insertinto@t_temp_referenced(tname,ttype,tlevel)
selecta.referenced_entity_name,b.xtype,@level+1from
(
selectdistinctreferenced_entity_namefromsys.sql_expression_dependencies
wherereferencing_id=object_id(@name)and[referenced_class]=1and[is_ambiguous]=0
)a
leftjoinsys.sysobjectsbona.referenced_entity_name=b.name
wherenotexists(select1from@t_temp_referencedt1
        wheret1.tname=a.referenced_entity_nameandt1.ttype=b.xtypeandt1.tlevel=@level+1)

fetchnextfromresultinto@name
end

closeresult
deallocateresult

set@level=@level+1
end

selectdistincttnamefrom@t_temp_referenced
wherettype=U
注重：sys.sql_expression_dependencies视图只要sql2008及以上版本才有，sql2005是没有的。
复制sys.sql_expression_dependencies视图的申明以下：

列名数据范例申明referencing_idint援用实体的ID。不成为Null。referencing_minor_idint援用实体为列时的列ID；不然为0。不成为Null。referencing_classtinyint援用实体的类。
1=工具或列
12=数据库DDL触发器
13=服务器DDL触发器
不成为Null。referencing_class_descnvarchar(60)对援用实体的类的申明。
OBJECT_OR_COLUMN
DATABASE_DDL_TRIGGER
SERVER_DDL_TRIGGER
不成为Null。is_schema_bound_referencebit1=被援用的实体绑定到架构。
0=被援用的实体未绑定到架构。
不成为Null。referenced_classtinyint被援用的实体的类。
1=工具或列
6=范例
10=XML架构汇合
21=分区函数
不成为Null。referenced_class_descnvarchar(60)对被援用的实体的类的申明。
OBJECT_OR_COLUMN
TYPE
XML_SCHEMA_COLLECTION
PARTITION_FUNCTION
不成为Null。referenced_server_namesysname被援用的实体的服务器的称号。
此列是为经由过程指定由四个部分构成的无效称号所天生的跨服务器依附干系添补的。有关由多个部分构成的称号的信息。
关于非绑定到架构的实体，假如实体被援用时没有指定由四个部分构成的称号，此列为NULL。
关于绑定到架构的实体，此列为NULL，缘故原由在于它们必需在统一数据库中，因此只能利用由两个部分(schema.object)构成的称号界说。referenced_database_namesysname被援用的实体的数据库的称号。
此列是为经由过程指定由三个部分或四个部分构成的无效称号天生的跨数据库或跨服务器援用添补的。
关于非绑定到架构的援用，当利用由一个部分或两个部分构成的称号指准时，此列为NULL。
关于绑定到架构的实体，此列为NULL，缘故原由在于它们必需在统一数据库中，因此只能利用由两个部分(schema.object)构成的称号界说。referenced_schema_namesysname被援用的实体所属的架构。
关于非绑定到架构的援用，假如实体被援用时没有指定架构称号，此列为NULL。
关于绑定到架构的援用，此列永不为NULL，缘故原由在于必需利用由两部分构成的称号来界说和援用绑定到架构的实体。referenced_entity_namesysname被援用的实体的称号。不成为Null。referenced_idint被援用的实体的ID。
关于跨服务器和跨数据库援用，此列一直为NULL。
关于数据库内的援用，假如没法断定ID，则为NULL。关于非绑定到架构的援用，在以下情形下将没法剖析ID：
被援用实体不存在于数据库中。
被援用的实体的架构依附于挪用方的架构，并在运转时剖析。在这类情形下，is_caller_dependent设置为1。
关于绑定到架构的援用，此列永久不会为NULL。referenced_minor_idint援用实体为列时被援用的列的ID；不然为0。不成为Null。
当列在援用实体中按称号标识时，大概当SELECT*语句中利用了父实体时，被援用的实体为列。is_caller_dependentbit唆使被援用的实体的架构绑定在运转时产生，因而，实体ID的剖析依附于挪用方的架构。当被援用的实体为存储历程、扩大存储历程或在EXECUTE语句中挪用的非绑定到架构的用户界说函数时，将会呈现这类情形。
1=被援用的实体依附于挪用方并在运转时剖析。在这类情形下，referenced_id为NULL。
0=被援用的实体ID不依附挪用方。
关于绑定到架构的援用、显式指定架构称号的跨数据库和跨服务器的援用，一直为0。比方，对格局为EXECMyDatabase.MySchema.MyProc的实体的援用不依附于挪用方。可是，格局为EXECMyDatabase..MyProc的援用依附挪用方。is_ambiguousbit唆使援用为不明白援用，并能够在运转时剖析为用户界说函数、用户界说范例(UDT)大概对xml范例的列的xquery援用。
比方，假定语句SELECTSales.GetOrder()FROMSales.MySales是在存储过程当中界说的。在实行存储历程之前，其实不晓得Sales.GetOrder()是Sales架构中的用户界说函数仍是带着名为GetOrder()的办法、范例为UDT且名为Sales的列。
1=援用不明白。
0=援用是明白的，大概在挪用视图时能够乐成绑定实体。
关于绑定到架构的援用一直为0。MySQL最初的开发者的意图是用mSQL和他们自己的快速低级例程(ISAM)去连接表格。经过一些测试后，开发者得出结论：mSQL并没有他们需要的那么快和灵活。

从底层原理到表层引用，书籍多的很。个人认为没有什么那本书好？这样的说法。主要看和个人的学习方法是否适合。

这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。

你可以简单地认为适合的就是好，不适合就是不好。

索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。

SP4是一个累积性的ServicePack，包含自以前的ServicePack发布以来所有的修补程序（包括MS03-031安全公告）。

sqlserver的痛苦之处在于有用文档的匮乏，很多只是表明的东西

having子句的作用是筛选满足条件的组，即在分组之后过滤数据，条件中经常包含聚组函数，使用having条件显示特定的组，也可以使用多个分组标准进行分组。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。