您可以有太多的存儲過程嗎？

Question

是否存在太多的存儲過程？

我知道您可以擁有的數量沒有限制，但這是不是出於性能或架構上的原因而不創造數百，數千個產品？

Answer 1

是的你可以。

如果您大於零，則太多

Answer 2

對我而言，成百上千個存儲過程的最大限制是可維護性。 即使這不是直接影響性能，也應該考慮。 這是體系結構的觀點，您不僅要計划應用程序的初始開發，還要計划未來的更改和維護。

話雖如此，您應該設計/創建您的應用程序所需的數量。 盡管使用Hibernate，NHibernate，.NET LINQ，我將嘗試在代碼中保留盡可能多的存儲過程邏輯，並且僅在速度是決定因素時才將其存儲在數據庫中。

Answer 3

我想這里更深層的問題是：所有這些代碼還應該放到哪里？ 視圖可用於通過標准SQL方便地訪問數據。 可以使用更強大的應用程序語言和庫來生成SQL。 存儲過程傾向於掩蓋數據的本質，並為系統引入不必要的抽象，復雜性和維護層。

有了對象關系映射工具生成基本SQL的能力，任何過度依賴存儲過程的系統的開發效率都將降低。 使用ORM，只需編寫更少的代碼。

Answer 4

除了在更改數據庫時還必須維護所有這些事實之外，您是否還意味着其他事實？ 那是我的重要原因。 最好是能夠處理多種方案的方案要少於只能處理一種方案的方案。

Answer 5

我只想提一提維護成為一個問題。 誰知道他們都是誰，他們服務什么目的？ 當它們只是一個遺留系統的產物而沒人能回想起它們的用途卻又害怕被弄亂時，那么幾年后會發生什么？

我認為最主要的問題是不可能，但應該這樣做。 多數民眾贊成在一個想法。

Answer 6

地獄是的，你可以有太多。 幾年前，我在一個系統上工作了10,000 proc。 太瘋狂了。 編寫系統的人員實際上並不知道如何編程，但是他們確實知道如何糾正結構錯誤的proc，因此他們將幾乎所有的應用程序邏輯都放入了proc中。 一些過程運行了數千行。 管理混亂是一場噩夢。

太多（我無法在沙子上畫出一條特定的線）可能表明設計不佳。 此外，正如其他人指出的那樣，有一些更好的方法可以實現粒度數據庫接口，而無需訴諸大量proc。

Answer 7

我的商業SQL Server 2005產品中我只有不到200個，對於某些新報告，它可能在未來幾天內再增加10-20個。

我會盡可能地編寫“子例程”存儲過程，以便每當我發現自己將3或4個相同的語句放入多個存儲過程中時，如果您明白我的意思了，就該將這幾個語句轉換為子例程。

我不傾向於使用sproc來執行所有的業務邏輯，我只是​​更喜歡讓sproc做任何可以被視為“事務性”的事情-因此在我的客戶端代碼（在Delphi中，但無論如何）可以執行以下操作：奇怪的插入或更新本身，一旦某些事情需要幾件事進行“一次”更新或插入，就該進行存儲了。

我有一個簡單的粗略命名約定，以幫助提高可讀性（和維護性！）

產品的代號為“ Rachel”，所以我們有

RP_whatever   - these are general sprocs that update/insert data, 
              - or return small result sets

RXP_whatever  - these are subroutine sprocs that server as 'functions' 
              - or workers to the RP_ type procs

REP_whatever  - these are sprocs that simply act as glorified views almost
              - they don't alter data, they return potentially complex result sets
              - for reporting purposes, etc

XX_whatever   - these are internal test/development/maintenance sprocs 
              - that the client application (or the local dba) would not normally use

命名是任意的，只是為了幫助區別SQL Server使用的sp_前綴。

我想如果我發現我可能會擔心數據庫中有400-500個存儲過程，但是只要您有一個系統來識別每個存儲過程負責哪種活動，那么數百個根本就不是問題。 我寧願追逐數百個sproc中的模式更改（SQL Server工具可以在其中幫助您找到依賴項等），而不是嘗試追逐我的高級編程語言中的模式更改。

Answer 8

我的問題是，如果要談論成百上千的存儲過程，為什么不使用某種中間件平台？

稱我為老式，但我認為數據庫應該只保存數據，而程序應該是制定業務邏輯決策的程序。

Answer 9

在Oracle數據庫中，您可以使用Packages將相關過程分組在一起。

其中一些，您的命名空間將釋放。

Answer 10

任何特定的事情太多，可能意味着您做錯了。 配置文件太多，屏幕上的按鈕過多...

不能代表其他RDBMS，但是使用PL / SQL的Oracle應用程序應該在邏輯上將過程和功能綁定到軟件包中，以防止級聯無效並更好地管理代碼。

Answer 11

對我而言，使用大量存儲過程似乎會使您朝着與PHP API等效的方向發展。 成千上萬與彼此無關的全局功能都歸為一類。 兩者之間唯一的聯系方式是采用某種命名約定，即在每個函數前面加上模塊名稱，類似於PHP中的mysql_函數。 我認為這很難維持，也很難保持一切一致。 我認為存儲過程對於確實需要在服務器上發生的事情非常有效。 一個簡單的選擇查詢，甚至帶有聯接的選擇查詢的存儲過程可能都已經走了。 僅在您實際上需要在數據庫服務器上處理高級邏輯的地方使用存儲過程。

Answer 12

正如其他人所說，這實際上歸結於管理方面。 過了一會兒，它變成了大海撈針。 當命名標准到位時，更是如此……

Answer 13

不，不是我所知道的。 但是，您應該為它們指定一個良好的命名約定。 例如，許多人喜歡用usp_來啟動它們（比以sp_開頭要快）。

也許您的報告存儲過程應該是usp_reporting_，而您的業務對象應該是usp_bussiness_，依此類推。只要您可以管理它們，那么擁有很多便不會有問題。

如果它們太大，則可能需要將數據庫拆分為多個數據庫。 這可能更合乎邏輯，可以幫助數據庫大小等。

Answer 14

如果您有很多存儲過程，則會發現您將自己綁定到一個數據庫-其中一些可能不容易轉移。

將自己綁定到一個數據庫並不是一個好的設計。

此外，如果您在數據庫和業務層上具有業務邏輯，那么維護將成為問題。

Answer 15

是的，您可能有太多存儲過程。

命名約定確實可以幫助您。 例如，如果您有一個命名約定，其中總是有表名和InsUpd或Get，那么很容易在需要時找到正確的存儲過程。 如果您沒有某種標准的命名約定，那么拿出兩個（或多個）幾乎可以完成完全相同的操作的過程將非常容易。

在沒有標准化命名約定的情況下，很容易找到以下幾個... usp_GetCustomersOrder，CustomerOrderGet_sp，GetOrdersByCustomer_sp，spOrderDetailFetch，GetCustOrderInfo等。

當您有很多存儲過程時，另一件事開始發生，您將擁有一些從未使用過的存儲過程，而有些則很少使用...如果您沒有某種跟蹤存儲過程使用情況的方法，要么將導致大量未使用的程序……或更糟的是，擺脫您認為從未使用過的程序，然后發現它僅每年一次或每季度一次使用。 :(

傑夫

Answer 16

當您擁有健全的命名約定，最新的文檔和足夠的單元測試來使它們井井有條時，就不會如此。

Answer 17

我的第一個大型項目是使用對象關系映射器開發的，該對象對數據庫進行了抽象，因此我們進行了所有面向對象的操作，並且更易於維護和修復錯誤，並且由於所有數據訪問和業務邏輯都是C＃代碼，因此更改特別容易，但是，當涉及到復雜的工作時，系統感覺很慢，因此我們不得不解決這些問題或重新設計項目，尤其是當ORM必須在數據庫中進行復雜的聯接時。

我現在在另一家公司工作，該公司的座右銘是“我們的應用程序只是數據庫的前端”，並且它有其優點和缺點。 我們擁有非常快速的應用程序，因為所有數據操作都是在存儲過程上完成的，這主要是使用SQL Server 2005，但是，當要進行更改或對軟件進行修復時，由於必須同時進行更改，因此很難， C＃代碼和SQL存儲過程，因此就像兩次工作一樣，與我使用ORM時相反，您在sql中沒有重構或強類型對象，Management Studio和其他工具會很有幫助，但通常您會花更多的時間這樣做。

因此，我要說的是，如果您不打算保留真正復雜的業務數據，那么就取決於項目的需求，甚至可以完全避免使用存儲過程，而要使用使開發人員工作變得更輕松的ORM。 如果您擔心性能並且需要節省所有資源，而不是使用存儲過程，那么數量當然會增加您設計的體系結構，因此例如，如果您始終有用於CRUD操作的存儲過程，則需要一個對於插入，一個用於更新，一個用於刪除，一個用於選擇，一個用於列出，因為這些是最常見的操作，如果您有100個業務對象，則將這4個對象相乘即可得到400個存儲過程，以便管理最基本的對對象的操作如此，是的，它們可能太多了。

Answer 18

我認為，只要您將它們命名為uspXXX而不是spXXX，按名稱進行的查找將是直接的，因此沒有缺點-盡管您可能想知道將procs泛化成千上萬個...

Answer 19

您必須將所有代碼放在某處。
如果您將要擁有存儲過程（我個人確實喜歡它們，但很多人則不喜歡），那么您可以根據需要使用它們。 至少所有數據庫邏輯都在一個地方。 不利的一面是，通常沒有太多的結構來存儲存儲過程的存儲桶。

你的來電！ :)