爲什麼使用「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將某些系統表確定爲「假表」？

回答

相關問題