我目前正在考慮基於現有數據集的報表應用程序的設計選項。通過存儲過程SQL Server代碼重用 - 好還是壞的做法？
考慮到許多報告需要使用相同的基本數據集（已編輯），有幾個明顯的代碼重用機會。
這種嘗試是爲了創建一些基本的存儲過程，我可以在整個系統中重用，但是，我在6個月前還是這麼做的合同讓我知道這種做法的缺點 - 多層 - 大存儲過程調用返回的數據子集，這使得正在進行的操作，調試和測試非常困難。
我認爲代碼重用不一定會增強數據庫設計的可維護性，
我正在尋找一些有關這方面的信息，從一個比我更有經驗的SQL Server開發者？
在此先感謝。
聲明：這不是「不要使用存儲過程 - 想到孩子們！」後，我不打算點燃火焰戰爭。我只是建議代碼重用更容易，可能更適合某些情況和平臺。
代碼重用作爲一個概念通常會改善代碼庫。你保留着東西DRY，並開始形成一個共同的功能層，以同樣的方式解決常見的問題。
然而，就像任何事情一樣，人們可以弄錯它（權力來自責任等等等等等等）。
在大多數現代編程語言中，通過編寫函數或者創建可以一次又一次使用的整個框架來重用代碼是相對簡單的。但是，在T-SQL中，這是棘手的，因爲你的選擇較少。存儲過程可以做到這一點，但是你已經看到了它們可能會有多尷尬。
我個人的偏好是保持業務邏輯不在數據庫中。這意味着我不使用視圖，UDF，sprocs等（除非在性能分析後我們認爲我們可以使用這些技術加快速度），而是將其保留在我的應用程序代碼中。這往往會引起「業務邏輯層」的思考，但有各種各樣的風格，所以它可能是一個誤用。不過，這當然不是直接位於UI按鈕點擊處理程序之後的代碼。
我的目標是限制數據庫存儲和檢索數據，因爲這就是他們擅長的。我們都知道笨重和過時的T-SQL可以作爲一種語言（想想異常處理，部署，遊標等）。如果您的應用程序被寫入數據庫本身，並且您也無法擴展您的應用程序，因爲數據庫不可知是完全不可能的，因爲數據庫是應用程序。如果您在應用程序代碼中擁有該業務邏輯，則可以更容易地擴展它。
在這種情況下，「業務邏輯」是用於生成報表的查詢和轉換，並且我將研究在考慮其他選項之前如何在報表工具/代碼中重用代碼。
代碼重用的主要目的是IMO，將單片程序分解爲更容易理解和更容易維護的部分。分工不應該是特殊的 - 一個人對秩序的個人古怪想法。構建輔助函數庫的技巧在很大程度上是一種社交藝術 - 您必須定義一個在其方法中一致的可理解的API。你不希望在你之後跟隨的編碼者缺席地詛咒你。您希望他們感謝您的設計的清晰度和實用性。
@Neil Barnwell：我發現將業務規則構建到數據庫中沒有問題。如果不是中間層或客戶端代碼更好，觸發器和存儲過程也可以執行此角色。當然，您必須擁有掌握數據庫，T-SQL或PL/SQL中的編程語言的程序員，或者任何它所發生的事情。
TSQL中的代碼重用需要根據具體情況進行。您需要養成檢查所寫的所有查詢的執行計劃的習慣，以確定計劃是否合理。
將視圖連接到視圖上可以正常工作，也可以導致效率低下，具體取決於它們的定義。
內聯表值函數可以是重用代碼的極好方法。他們避免了可能的謂詞推送視圖問題，並且當它們被查詢優化器擴展時，它們允許您比使用多語句TVF或存儲過程結果集嘗試做同樣的事情更有效地對結果應用過濾器。
「我現在認爲代碼重用不一定會增強數據庫設計的可維護性。」是主要問題，其餘部分是針對上下文的。 – gb2d 2011-01-19 12:39:57
存儲過程的標題中是否有任何特定限制的原因？這些不是代碼重用的唯一機制。 – 2011-01-19 12:44:14
不是。我知道有幾種方法可以實現代碼重用。 – gb2d 2011-01-19 12:45:39