儲存過程中“暫存”關係的最佳實踐：使用臨時表還是視圖？

當我編寫接受relation A和輸出的儲存過程時relation Z，我喜歡在此過程中創建“暫存”關係，以便在應用程式邏輯的每個步驟後檢查數據的狀態。

到目前為止，我一直在使用臨時表來實例化這些暫存關係。

我應該改用視圖嗎？如果是這種情況，那麼當不同的視圖連接到同一個查詢中，並且這些不同的視圖訪問同一個基表時會發生什麼？性能會受到影響嗎？

總體而言，哪種方法可以帶來最佳的整體性能？有沒有辦法給出適用於大多數場景的一般答案，而無需對特定實現進行跟踪？

如果您這樣做是為了幫助調試，而不是為了便於在失敗後重新啟動。我會建議臨時表。

臨時表僅對創建它們的範圍可見。換句話說，如果兩個使用者同時執行相同的儲存過程 (SP)，他們將獲得不同的臨時表，最重要的是，他們的數據將彼此完全隔離。視圖是全域可見的（權限不受限制），一個人寫入的數據可以被所有人看到，有洩漏的風險。如果您定義視圖並將工作值寫入其中，則必須添加額外的列以將您的值與其他使用者的值分開。

當臨時表超出範圍時，系統會自動刪除它們。這使您的調試程式碼更簡單，因為您不必在崩潰後圍繞臟重啟進行程式。

SELECT..INTO可以使用語法即時創建臨時表。因此，他們的模式將自動跟上周圍模式的變化。視圖沒有這個優勢。

如果您正在處理許多行，則可以索引 Temp 表，但其缺點與索引普通表相同。至少在 SQL Server 中——這是我的專長——視圖的定義在被索引之前有很多限制，這可能會影響它們在您的情況下的性能或適用性。

SQL Server 使表值變數可用作臨時表的輕量級替代方案。有關差異，請參閱此 SO 問題。

如果您碰巧在 SQL Server 上，並且幸運地擁有 2014 年可用，並且您的行數適中，那麼這些工作表是非持久記憶體表的絕佳候選者。

引用自：https://dba.stackexchange.com/questions/63767