如果您可以在該服務器上創建新數據庫,則可以在新數據庫中創建視圖。視圖可以使用三部分名稱訪問數據。例如。從OtherDB.dbo.Table中選擇*。
如果您有權訪問另一個SQL服務器,DBA可以創建一個「鏈接服務器」。然後,您可以創建使用四部分名稱訪問數據的視圖。例如。 select * from OtherServer.OtherDB.dbo.Table
無論哪種情況,數據總是「活」的,所以不需要擔心臟數據。
這些視圖將爲您帶來更簡潔的代碼和單個位置以進行更改,並且緩存的執行計劃可爲您帶來幾毫秒的性能優勢。但是,不應該有很大的表現飛躍。您提到緩存,但據我所知,服務器不會爲特殊查詢所不會執行的任何特殊的數據緩存用於普通的非索引視圖。
如果您還沒有這樣做,您可能希望做一些實驗來確定視圖是否真的更快 - 製作數據庫的副本並在其中添加視圖。
編輯:我今天做了一個類似的實驗。我在Server1上存儲了一個通過鏈接服務器從Server2獲取數據的proc。這是一個複雜的查詢,連接了兩臺服務器上的許多表。我在Server2上創建了一個視圖,該視圖從服務器獲取所需的所有數據,並更新了proc(在Server1上),以便它使用該視圖(通過鏈接服務器),然後將視圖加入到一堆表中在Server1上。更新後顯着更快。原因似乎是Server1錯過了從Server2獲得的行數,從而構建了一個糟糕的計劃。在使用視圖時,它估計得更好。如果視圖與其讀取的數據位於同一個數據庫中並不重要,它只需要放在同一個服務器上(我只有實例,所以我不知道實例是如何起作用的) 。
如果您已經在使用鏈接服務器來獲取數據,這種特殊場景纔會起作用,因此它可能與原始問題無關,但我認爲這很有趣,因爲我們正在討論視圖的性能。
您是否有權創建存儲過程? – 2009-11-19 21:56:50
爲什麼你認爲視圖會更快? – HLGEM 2009-11-19 22:08:29
不,我可以*只讀*數據。 視圖被緩存。 – Loki 2009-11-19 22:10:55