你可以與系統表/視圖有關係嗎？

是否有可能從用戶表到系統表視圖有關係？爲了給出上下文，我希望我的一個表中列的值限制爲另一個表的列名，這似乎最容易通過瀏覽包含列的系統視圖來完成第二個表的名稱。你可以與系統表/視圖有關係嗎？

因此，如果使用經典示例，如果我有一個Customers（FirstName LastName）表，我想創建另一個具有隻能是「FirstName」或「LastName」的「customerAttribute」列的表。爲了保持這種動態性，如果「customerAttribute」列實際上是系統視圖中存儲Customer列中列名稱的外鍵，這樣，我就不必擔心數據完整性問題，因爲在實際Customers表中添加，刪除和重命名列。

我沒有看到在SQL Server中創建這種關係的簡單方法，所以我想知道是否混淆/創建與系統表和/或視圖的關係是一個主要的禁忌。

謝謝！

P.S.我問這個問題，以幫助我解決another problem我發佈在SO上。

編輯：即使無法直接與系統視圖建立關係，也許可以創建一個視圖，該視圖將查詢返回到系統視圖（以獲取列名稱），然後與該視圖建立關係。我現在就試試。

來源

2009-06-30 JoeCool

我希望我永遠不必在這樣設計的系統上工作。 – 2009-06-30 20:31:02

你可以但我不知道它是否合法;）抱歉無法拒絕 – Janusz 2009-06-30 20:33:39

顯然沒有什麼可以阻止您創建引用系統表列的用戶表列。所以顯而易見的答案是肯定的。要回答你真正的問題，有必要問一個不同的問題，即：在用戶表中存儲元數據是一個好主意嗎？

如果我要從數據管理純粹主義者的角度回答，我會說這幾乎總是一個壞主意。然而，實際上，儘管我並不以此爲榮，但我做到了。通過混合數據和元數據可以獲得一些結果，這些數據和元數據在不混合的情況下幾乎不可能實現。

您運行的風險是，最終您最終會得到一個數據庫，該數據庫無法用對主題專家有意義的屬性進行記錄。換句話說，您的數據庫只能由您自己和您的同事使用。有時候這是一個可接受的風險。有時不是。

來源

2009-06-30 20:27:06

我不確定這是否是可能的，但如果是的話，那麼你肯定是踩在危險的地面上......你如何重新命名一列？你將如何移動一列？你會如何刪除列？這種類型的東西可能會在SSMS內部破碎。這種類型的東西最好用觸發器或代碼邏輯處理。

來源

2009-06-30 20:24:56

依賴於系統表總是一個壞主意，因爲MS可以在不發出警告的情況下更改它們。爲什麼不使用information schema views，它們是可移植的，並支持需要查詢元數據的應用程序？

來源

2009-06-30 20:27:04

你可以與系統表/視圖有關係嗎？

回答

相關問題