SQL Server 文档 here表示 information_schema.tables
的 table_schema
字段“不可靠”,获取对象架构的正确方法是查询 sys.objects
.
任何人都可以详细说明 information_schema.tables
报告的模式如何以及何时可能不正确吗?
最佳答案
很遗憾,这个问题没有得到答复,只是出于代表的贪婪而发表了评论,更重要的是,为了将其从未答复的队列中删除,我将在答案中提出几点。
文档中的措辞不准确,正在更正中(参见 Connect #686118 )。我不确定他们是否会一次性纠正 2005、2008 和 2008 R2 文档,或者旧版本是否会得到更新。关键是,我无法想象任一 View 中的架构不正确的情况,但更重要的是, info_schema 不正确,而
sys.objects
是正确的。后者是不可能的 - info_schema View 完全基于sys.objects
View (只需查看SELECT OBJECT_DEFINITION (OBJECT_ID ('INFORMATION_SCHEMA.TABLES'));
),因此如果其中一个不正确,则它们都是不正确的。可能存在一些模糊的情况,它们都可能不正确,但在当前版本中不会(例如,在 SQL Server 2000 中,启用配置选项allow updates
时,从 sysusers 中删除拥有对象的用户 - 并不真正相关或不可能今天,这不是我愿意尝试的事情,但这是我能想象的唯一会在任何时间点激发当前措辞的事情)。一般来说,
INFORMATION_SCHEMA
应避免使用 View ,而应使用 SQL Server 2005 中引入的目录 View (并从那时起进行了扩充)。为什么?因为随着新功能添加到 SQL Server,目录 View 仍在不断开发,而 info_schema View 却没有。正如我在评论中提到的,尝试在 info_schema 中查找有关过滤索引的信息。包含的列、XML 索引、身份/计算列、针对唯一索引的外键也是如此 - 这些都要么完全缺失,要么在 info_schema View 中以不同的方式表示。在 Denali 中,他们为序列添加了一个 info_schema View ,但这再次满足了最低限度的标准,并且不包含有关 SQL Server 特定实现细节的任何信息(例如,它是否已用尽,以及他们是否在将来您可以确定 info_schema View 不会保留在循环中)。您坚持使用 info_schema View 的唯一情况是 (a) 您正在编写需要跨 info_schema 兼容平台工作的元数据例程并且 (b) 您没有使用任何特定于平台的功能那将会被错过。除了多平台供应商工具之外,这可能是一种非常罕见的情况(即使在这种情况下,也可能会导致正在使用这些功能而工具没有选择这些功能的客户感到不满)。 p>- 我提交了单独的 Connect 建议 ( Connect #686121 ),要求他们在所有
INFORMATION_SCHEMA
上张贴有关此不完整性的警告。查看联机丛书中的主题。我认为人们并不知道它们不是从 SQL Server 获取元数据的首选方式,谁能责怪人们没有看到这一点 - 毕竟,我们总是被告知使用符合标准的方法是“最佳实践”,而使用专有方法则相反。与许多数据库事物一样,“这取决于” - 但我怀疑,通常情况下,您最好使用sys
目录 View ,除非您处于一种罕见的情况,即您仅使用 SQL Server 中标准通用的功能。我认为我还没有遇到过任何一个这样的例子,但如果它们确实存在,我会非常高兴地了解它们。
我还在博客中提到了 INFORMATION_SCHEMA
的不可靠性这里:
关于sql-server - SQL Server 上的 information_schema 架构信息不可靠?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7217886/