且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

SQL Server 上的不可靠 information_schema 架构信息?

更新时间:2023-02-09 23:13:37

很遗憾,这个问题没有得到答复,只是部分出于代表的贪婪而发表评论,更重要的是为了让它摆脱未答复的队列,我会抛出一些指向答案.

It's a shame this went unanswered and just commented so partially out of rep greed and more importantly to get it out of the unanswered queue, I'll throw a few points into an answer.

  1. 文档中的措辞不准确,正在修正中(参见连接 #686118).我不确定他们是否会一次性更正 2005、2008 和 2008 R2 文档,或者是否会更新旧版本.关键是我无法想象任一视图中的架构不正确的情况,但更重要的是,info_schema 不正确而 sys.objects 是正确的.后者是不可能的 - info_schema 视图完全基于 sys.objects 视图(只需查看 SELECT OBJECT_DEFINITION (OBJECT_ID ('INFORMATION_SCHEMA.TABLES'));),所以如果一个是不正确的,那么它们都是不正确的.可能有一些模糊的情况,它们都可能不正确,但不是在当前版本中(例如,在 SQL Server 2000 中,启用配置选项 allow updates,从 sysusers 中删除拥有对象的用户- 今天不是真的相关或可能,也不是我愿意尝试的东西,但这是我能想象的唯一一种会在任何时候激发当前措辞的东西).

  1. The wording in the documentation is not accurate, and it is in the process of being corrected (see Connect #686118). I'm not sure if they will correct the 2005, 2008 and 2008 R2 docs all at once, or whether the older versions will even get updated. The point is that I can not envision a case where the schema in either view is incorrect, but even more so, that info_schema is incorrect while sys.objects is correct. The latter is impossible - the info_schema view is based entirely on the sys.objects view (just look at SELECT OBJECT_DEFINITION (OBJECT_ID ('INFORMATION_SCHEMA.TABLES'));), so if one is incorrect, they're both incorrect. There are probably obscure cases where they can both be incorrect, but not in current versions (for example, in SQL Server 2000, with the config option allow updates enabled, delete from sysusers a user who owns an object - not really relevant or possible today, and not something I'm willing to try, but it's the only one I can imagine would have motivated the current wording at any point in time).

一般来说,应避免使用 INFORMATION_SCHEMA 视图,而应使用 SQL Server 2005 中引入的目录视图(并从那时起进行了扩充).为什么?因为随着新功能添加到 SQL Server,目录视图继续开发,而 info_schema 视图没有.正如我在评论中提到的,尝试在 info_schema 中查找有关过滤索引的信息.包含的列、XML 索引、身份/计算列、针对唯一索引的外键也是如此——这些都要么完全缺失,要么在 info_schema 视图中以不同的方式表示.在 Denali 中,他们为 Sequences 添加了一个 info_schema 视图,但这再次满足了标准的最低要求,并且不包含有关 SQL Server 特定实现细节的任何信息(例如,是否已用完,以及他们是否在将来您可以确定 info_schema 视图不会保留在循环中).您坚持使用 info_schema 视图的唯一情况是,如果 (a) 您正在编写需要在符合 info_schema 的平台上工作的元数据例程AND (b) 您没有使用任何特定于平台的功能那将被错过.除了多平台供应商工具之外,这可能是一种非常罕见的情况(即使在这种情况下也可能导致客户不满意,他们使用这些功能而该工具没有选择它们).>

  • 我提交了单独的 Connect 建议(Connect #686121) 他们在所有 INFORMATION_SCHEMA 上贴上了关于这种不完整性的警告 查看联机丛书中的主题.我不认为人们很清楚它们不是从 SQL Server 中获取元数据的首选方式,谁能责怪人们没有看到这一点 - 毕竟,我们总是被告知使用符合标准的方法是***实践",而使用专有方法则相反.与许多数据库事物一样,这取决于" - 但我怀疑,通常情况下,您***使用 sys 目录视图,除非您处于那种罕见的情况下仅使用 SQL Server 中标准通用的功能.我不认为我遇到过以任何身份出现这种情况的单个实例,但如果它们确实存在,我很高兴知道它们存在.
  • In general, INFORMATION_SCHEMA views should be avoided in favor of the catalog views introduced in SQL Server 2005 (and augmented since then). Why? Because the catalog views continue being developed as new features are added to SQL Server, while the info_schema views have not. As I mentioned in my comment, try to find information about filtered indexes in info_schema. Same goes for included columns, XML indexes, identity/computed columns, foreign keys against unique indexes - these are all either missing entirely or represented differently in the info_schema views. In Denali they added an info_schema view for Sequences but again this meets the bare minimum of the standard and doesn't include any information about SQL Server-specific implementation details (for example, whether it's exhausted, and if they add any new features in the future you can be sure the info_schema view will not be kept in the loop). The only case where you would stick to info_schema views is if (a) you are writing metadata routines that need to work across info_schema-compliant platforms AND (b) you aren't using any platform-specific features that will be missed. Aside from multi-platform vendor tools this is probably a pretty rare scenario (and even in that case may lead to displeased customers who are using those features and the tool didn't pick them up).

    我还在博客上写了关于 INFORMATION_SCHEMA 的不可靠性的文章:

    I've also blogged about the unreliability of INFORMATION_SCHEMA here: