MSSQL网站制作之SQL Server 2005：向体系表说再会
这章描述如何检查和处理在MySQL数据库中的数据损坏。如果你的表损坏很多，你应该尝试找出其原因!见G.1调试一个MySQL服务器。微软的SQLServer数据库办理员，快快想一下!在不利用任何的文档的情形下，编写一个查询，从SQLServer2000体系表中抽取索引的列表，然后枚举每一个索引中的字段，并判别这个字段是不是依照升序大概降序举行排序。你有两分钟的工夫。快!假如你如今真的停下浏览，入手下手用必不成少的两分钟工夫思索这项不奉迎的义务，那末如今你就堕入了一个年夜贫苦中，这内里触及了体系索引、体系索引关头字，体系字段，和一些元数据函数，个中包含相似OBJECT_NAME和INDEXKEY_PROPERTY如许的备用信息。到如今为止，要编写如许的一个查询很分明要消费远远凌驾2分钟的工夫了。
不幸的SQLServer2000数据库办理员们，必要扫瞄深邃的体系表，这是这项利用数据库办理体系的事情中最糟的一部分。体系表，一般是无效率的，可是在我的印象里，它可历来不是为了用户友爱计划的。
侥幸的是，长远就有了救星。在SQLServer2005中，体系表不见了。是的。不见了。不再必要对生疏的位举行操纵，也不必要找入迷秘的编码计划――这在已往都是必须的。关于你们两头必要对遗留上去的参考这些表的人来讲，我晓得你在想甚么:无停止的机器的晋级以保证与SQLServer2005的兼容。可是还不要心生讨厌。体系中仍旧存在相似体系表的工具，就是为了向下兼容的目标。可是表的本身是――大概是实践上应当是――被忘记，像8-tracks和Tab一样被投进了汗青的渣滓桶中。
那末这些表往了那里呢?SQLServer2005中的体系数据如今存储在埋没的“资本”表中，这个表只能被服务器本身间接会见。初级用户(和数据库办理员)必需利用新的一系列的分类视图，这些视图显现了从各类我们看不到也不克不及挪用的埋没表和各类埋没函数中取得的数据。之前版本的SQLServer中的体系体现在作为一系列所谓的(也相称准确的)“兼容视图”的情势完成。
分类视图和它们的同伴，静态办理视图(上面举行注释)，代表了一种处置元数据的体例，这些元数据是完整从头计划和从头思索出来的。没有了那些只会给数据库办理员一些底层数据的巨大感到的奥秘的表，如今的SQLServer供应了丰厚的资本:SQLServer2005中有凌驾200个分类和办理视图，代替了之前版本中约莫50个的体系表。
一切这些视图都能够在体系企图中找到。(企图是在SQLServer2005中年夜年夜扩大了的平安特征。可是这是另外一篇贴士的话题。)要看到可用视图的完整列表，SQLServerManagementStudio扩大了一切数据库的体系视图树。大概经由过程T-SQL从视图本身选择一个列表，并找出友爱的易于了解的名字:
SELECTname
FROMsys.all_views
WHEREis_ms_shipped=1
你还会发明不再必要经由过程扫瞄文档来查找有关做某件干系体系数据的事变的线索。这些视图都有很明白的自我注释。
有关视图名字的一些线索以下:那些前缀是dm_的是静态办理视图，经由过程相似以后会话、锁，和体系资本的信息暗示服务器的正在改动的形态。其他的视图都能够以为是分类视图。那些前缀是all_的包括了有干系统工具(比方视图)和用户界说的工具的信息。那些没有all_前缀的只包括了用户界说的工具的信息。在那些包含了体系工具的视图中，is_ms_shipping字段可用于辨别用户界说工具和体系工具。假如is_ms_shipped字段的值为1，则这一行代表了一个体系工具，不然，就是用户界说的工具。
最初，让我们反省一些你能够从分类视图中取得数据范例。关于初学者，一切罕见的内容都能够取得。比方:检察索引中的数据，利用sys.indexes，而不是本来的sysindexes――奇异的是，如今称之为sys.sysindexes。关于束缚，尝尝sys.check_constraints,sys.default_constraints,大概sys.key_constraints。看出这个趋向了吗?
这篇贴士哪怕是没有复杂的提到一句有关新的静态办理视图的话，都是不完全的。这些视图是SQLServer存储新的元数据的强无力的工具，它们能够匡助数据库办理员疾速办理成绩并剖析服务器的功能。个中的一些明星选手，包含sys.dm_exec_query_stats，用来呈报查询请求了几个处置器工夫;和sys.dm_db_index_usage_stats，用来匡助数据库办理员决意哪个索引是最有效的，哪些是没有效的。
关于这个伟大的元数据视图汇合，另有更多的话必要说。可是如今，能够看看比来由微软公布在网上的beta版的SQLServer2005在线书本。体系视图主题供应了对这个壮大的新的数据堆栈的才能的全体形貌。
别的，以下是谁人2分钟成绩的办理计划。起首利用SQLServer2000体系表。其次，能够尽早地浏览有关SQLServer2005分类视图的译本。
在JOIN操作中（需要从多个数据表提取数据时），MySQL只有在主键和外键的数据类型相同时才能使用索引。 外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。 语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！ 而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~ 外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。 索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。 对一张百万级别的表建游标，同时又没有什么过滤条件，取得游标效率是如果直接SQL查询百万条数据；如果再对每条记录做处理，耗时将更长。 无法深入到数据库系统层面去了解和探究 原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！
页:
[1]