微软的SQL Server 数据库管理员 ,快快想一下!在不使用任何的文档的情况下,编写一个查询,从SQL Server 2000系统表中抽取索引的列表,然后列举每个索引中的字段,并判断这个字段是否按照升序或者降序进行排序。
微软的SQL Server 数据库管理员 ,快快想一下!在不使用任何的文档的情况下,编写一个查询,从SQL Server 2000系统表中抽取索引的列表,然后列举每个索引中的字段,并判断这个字段是否按照升序或者降序进行排序。你有两分钟的时间。快!
如果你现在真的停下阅读,开始用必不可少的两分钟时间思考这项不讨好的任务,那么现在你就陷入了一个大麻烦中,这里面涉及了系统索引、系统索引关键字,系统字段,以及一些元数据函数,其中包括类似OBJECT_NAME 和INDEXKEY_PROPERTY这样的备用信息。到现在为止,要编写这样的一个查询很明显要花费远远超过2分钟的时间了。
不幸的SQL Server 2000数据库管理员们,需要浏览深奥的系统表,这是这项使用数据库管理系统的工作中最糟糕的一部分。系统表,通常是有效率的,但是在我的印象里,它可从来不是为了用户友好设计的。
幸运的是,眼前就有了救星。在SQL Server 2005中,系统表不见了。是的。不见了。再也不需要对陌生的位进行操作,也不需要找出神秘的编码方案——这在过去都是必需的。对于你们中间需要对遗留下来的参考这些表的人来说,我知道你在想什么:无休止的机械的升级以保障与SQL Server 2005的兼容。但是还不要心生厌恶。系统中仍然存在类似系统表的对象,就是为了向下兼容的目的。但是表的自身是——或者是实际上应该是——被遗忘,像8-tracks 和 Tab一样被投入了历史的垃圾桶中。
那么这些表去了哪里呢?SQL Server 2005中的系统数据现在存储在隐藏的“资源”表中,这个表只能被服务器自身直接访问。低级用户(和数据库管理员)必须使用新的一系列的分类视图,这些视图显示了从各种我们看不到也不能调用的隐藏表和各种隐藏函数中获得的数据。以前版本的SQL Server 中的系统表现在作为一系列所谓的(也相当正确的)“兼容视图”的形式实现。