我在執行對學生的一些操作的類設置基於操作和調用存儲過程
在它更新的一些基於一些標準的學生狀態的最後一步一個存儲過程的工作。
這一切都很簡單，但我在這裏有一個困境。 基本上沒有在系統中的現有SP稱爲
pUpdateStudentStatus(studentID, statusID, comments, userID)
該SP是由應用程序使用每當單個用戶的狀態將被更新。除了更新狀態之外，它還將更改記錄在StudentStatusHistory表中。
因此，這裏是我的困境，
是否有任何其他選項？你會選哪一個？
相信隨着更新觸發器的另一種方法是不是很長的路要走，因爲我需要一些額外的細節，如改變了狀態的用戶的用戶id和評論
我使用SQLServer2005的
您不會說pUpdateStudentStatus是由您掌控還是由第三方創建。
如果它是第三方SP，我不認爲你有很多選擇，只能使用遊標/循環，因爲SP的內部可能會在將來的版本中發生變化。
如果SP受你控制，另一個選擇是創建一個版本爲pUpdateStudentStatus的新名稱，該新名稱將以基於集合的方式運行（可能通過接受變量的表變量），然後重寫現有的pUpdateStudentStatus充當一個包裝器，用參數表中的單個行調用新過程。
如果你想保持操作集的基礎，那麼是的，可悲的是，你需要從pUpdateStudentStatus複製和粘貼sql。
您需要在基於集合的更新的性能和代碼的重用（以及易於維護）之間做出決定。我知道我通常會選擇哪一種，但是您的選擇取決於您對性能和其他考慮的需求。
我通常保持操作設定爲主，但這次我可以破例，主要是因爲其他的代碼編寫和其他開發人員和受影響的記錄數保持在非常小的，所以性能不應該是一個問題在這裏。我想知道是否有其他選擇。 – kristof 2009-04-15 11:18:03
就個人而言，除非表現是一個問題（聽起來這很可能是偶爾運行的工作，甚至可能在工作時間以外安排），我會循環現有的程序。 CPU總是比DBA /程序員時間便宜，維護考慮應該超越效率，除非不這樣做會對業務產生影響。無論採用哪種方式，您都應該記錄爲什麼您採用了您在代碼中選擇的任何方法。另外，如果你還沒有文檔體系，我建議在數據庫中用（至少）sp名和描述性文本建立一個簡單的文檔表。由於存儲過程/用戶定義函數的性質，可以對實現哪些功能的情況進行全面控制，除非採用某種策略，並且我看到太多的數據庫存在大量存儲過程/ udfs，而且沒有在哪裏實施哪些功能的簡單方法。如果你的團隊支持版本控制和完整的文檔，你可以稱讚它，但如果沒有可用的文檔，那麼記錄它本身的數據庫是簡單，強大和快速獲勝的。
受影響的記錄數量非常少，因此性能不應該成爲問題。循環似乎是這種情況下的最佳選擇。 – kristof 2009-04-15 11:58:53
如果你正在做少量的記錄，循環是可以接受的，但是如果批處理過程變得很大，你將需要基於集合的代碼。
的其他選擇，如果你最終需要的基於集合的邏輯是改變proc，這樣無論是基於集合或個人插入到建議其他什麼。通過將參數設置爲可選的（您的GUI需要檢查以確保爲單個插入傳遞所有必需的參數）並添加參數以便傳入以進行基於集合的操作，您可以將邏輯放在一個PROC。
如果批號爲空，請執行當前操作。如果它被傳遞到proc的批處理部分。對於批處理，insert proc可以由另一個proc生成一個新的批處理編號，將要插入的信息插入到包括批處理編號的工作表中。那麼它使用batchnumebr作爲插入過程的輸入參數。
你仍然將不得不寫這兩種情況的邏輯，但由於它們是在同一個進程內，他們會更容易維護，你將不太可能忘記更新這兩個進程。
謝謝埃德，創建一個新的基於SP的版本聽起來像一個有趣的解決方案。在這種特殊情況下，我不能使用表變量（sqlServer2005），但我一般喜歡這個想法。 – kristof 2009-04-15 11:28:33