information_schema.tables的table_schema字段是“不可靠的”，正确获取对象模式的方法是查询sys.objects。请问是否有人可以详细说明何时和如何出现information_schema.tables报告的模式不正确的情况？很遗憾这个问题没有得到解答，只是因为一些声望的贪欲和更重要的是想把它从未解决的队列中移除，我会回答一些。
文档中的措辞不准确，正在进行修改（请参见连接＃686118）。 我不确定他们是否会同时纠正2005年、2008年和2008 R2年的文档，或者更早版本是否会得到更新。但有一点是，在任一视图中，我都不能想象模式不正确的情况，更何况info_schema不正确，而sys.objects正确。后者是不可能的——info_schema视图完全基于sys.objects视图（只需查看SELECT OBJECT_DEFINITION(OBJECT_ID('INFORMATION_SCHEMA.TABLES'));），因此如果一个不正确，则两个都不正确。可能有些鲜为人知的情况，两者都不正确，但在当前版本中不存在（例如，在启用配置选项allow updates的SQL Server 2000中，从拥有对象的用户sysusers中删除一个用户——这不太相关或可能今天不可能发生，也不是我愿意尝试的事情，但这是我能想象到的唯一一个会在任何时候激发当前措辞的情况）。
INFORMATION_SCHEMA 视图，而是使用自 SQL Server 2005 引入并自那以后增强的目录视图。为什么呢？因为随着 SQL Server 的新功能不断添加，目录视图继续得到开发，而 info_schema 视图则没有。正如我在评论中提到的，尝试在 info_schema 中查找关于过滤索引的信息。同样的情况也适用于包含列、XML 索引、标识/计算列、针对唯一索引的外键 - 这些要么完全缺失，要么在 info_schema 视图中表示方式不同。在 Denali 中，他们为序列添加了一个 info_schema 视图，但是这只满足标准的最低要求，并且不包括任何关于 SQL Server 特定实现细节的信息（例如，它是否已用尽，如果将来添加任何新功能，则可以确定 info_schema 视图不会跟上）。唯一需要坚持使用 info_schema 视图的情况是：（a）您正在编写需要在 info_schema 兼容平台上工作的元数据例程并且（b）您没有使用任何将被忽略的特定于平台的功能。除了多平台供应商工具之外，这可能是一个相当罕见的情况（即使在这种情况下，可能会导致不满意的客户，他们使用了那些工具没有获取到的功能）。INFORMATION_SCHEMA 视图主题上都贴上关于这种不完整性的警告。我认为很少人知道它们并不是从 SQL Server 获取元数据的首选方式，谁能责怪他们没有看到呢——毕竟，我们总是被告知使用符合标准的方法是“最佳实践”，而使用专有的方法则相反。像许多数据库事物一样，“这要看情况”——但我怀疑，除非您仅使用标准通用功能，否则更多时候最好使用 sys 目录视图。我还没有遇到过任何情况，即使在任何情况下都只使用标准通用功能的情况，但如果确实存在这样的情况，我会非常乐意了解。我还在这里发表了关于 INFORMATION_SCHEMA 不可靠性的博客：
EXEC sp_helptext 'INFORMATION_SCHEMA.TABLES'的输出，这确实使用了sys.objects，所以看起来有点奇怪。 - Martin Smithsys目录视图来获取元数据，而不是INFORMATION_SCHEMA，主要是因为前者将被扩展以支持新功能，但后者将相对停滞不前。（例如，尝试使用INFORMATION_SCHEMA查找有关过滤索引的信息。） - Aaron BertrandLEFT JOIN操作？在我看来，这表明有一些情况下模式可能无效（但我头脑中无法想象）。但是警告消息（包括所有不正确的语法）毫无意义，因为这意味着sys.objects指向的sys.schemas中的行也是无效的，那么使用sys.objects（或更合适的sys.tables）会比INFORMATION_SCHEMA更可靠吗？ - Aaron Bertrandsys.sysobjects中的模式信息可能不正确如此处所述。也许他们只是在一些事情上贴了太多的警告？ - Martin Smith