为什么使用“TableIsFake”ObjectProperty将某些系统表确定为“假表”？

我在看今天的ObjectProperty列表，并遇到财产TableIsFake。这个名字使我感到好笑，所以我看着它检查什么：为什么使用“TableIsFake”ObjectProperty将某些系统表确定为“假表”？

这张表是不是真的。它由SQL Server按需内部实现。

这是什么意思？例如，当我运行以下查询：

SELECT [name], xtype 
FROM dbo.sysobjects 
WHERE OBJECTPROPERTY(object_id([name]), N'TableIsFake') = 1 
ORDER BY [name]

我得到如下结果：

name   xtype 
-------------- ----- 
sysfiles  S 
sysforeignkeys S 
sysindexkeys S 
sysmembers  S 
sysprotects S

但是，如果我查询系统表的数据库：

SELECT [name], xtype 
FROM dbo.sysobjects 
WHERE xtype = 'S' 
ORDER BY [name]

我得到的以下系统表：

name    xtype 
------------------- ----- 
syscolumns   S 
syscomments   S 
sysdepends   S 
sysfilegroups  S 
sysfiles   S 
sysfiles1   S 
sysforeignkeys  S 
sysfulltextcatalogs S 
sysfulltextnotify S 
sysindexes   S 
sysindexkeys  S 
sysmembers   S 
sysobjects   S 
syspermissions  S 
sysproperties  S 
sysprotects   S 
sysreferences  S 
systypes   S 
sysusers   S

是什么使sysfiles,sysforeignkeys,sysindexkeys,sysmembers,sysprotects系统表“假”？或者换一种说法，这意味着它们是“通过SQL Server内部实现的”。这是否意味着它们只在流程需要时才创建，或者如果我打电话给SELECT * FROM sysfiles？

来源

2011-05-05 LittleBobbyTables

一个假表是一种特殊的“内存”结构，没有磁盘上的持久性。 SQL Server按需创建它。

最好的例子是sysprocesses。

IMHO：关键是“在磁盘上的持久性”：

sysusers中或在sysxlogins（例如）是在每个分贝/主真实的表分别和生存的备份/恢复
sysprocesses中或sysfiles不会生存备份/恢复，因为没有什么可以写入或读取到磁盘

来源

2011-05-09 16:26:22 gbn

有道理，但任何想法，为什么'USE主; SELECT OBJECTPROPERTY（OBJECT_ID（'sysprocesses'），N'TableIsFake'）'返回NULL而不是'1'？ – 2011-05-10 17:07:57

@Martin：sysprocesses是一个兼容性视图... – gbn 2011-05-10 18:02:40

的sysfiles表确实是一个视图，并创建这样的向后兼容性见Mapping System Tables to System Views看你应该使用

所以不是sysfiles的是什么，你应该使用sys.database_files中

来源

2011-05-05 20:56:25 SQLMenace

我忘了提及我在SQL Server 2000中测试这个。编辑我的问题标签。 – LittleBobbyTables 2011-05-05 20:59:41

为什么使用“TableIsFake”ObjectProperty将某些系统表确定为“假表”？

回答

相关问题