小方法 - 小sprocs

Question

叔叔鮑勃建議有小方法。存儲過程是否有理想的大小？或者他們可以跑100和100的線路長嗎？

也沒有人有話要說在哪裏放置業務邏輯。如果位於存儲過程中，則該數據庫將用作數據處理層。

如果您閱讀Adam Machanic，他偏向於數據庫，那麼這是否意味着只有sproc的作者才能理解的長存儲過程，讓維護人員處理混亂？

我想有兩個相互關聯的問題，不知何故。

預先感謝您回答模糊問題。

Answer 1

我會盡可能將相同的建議應用於SP，因爲我認爲SP的代碼。

我認爲業務邏輯屬於代碼庫的一層，而不是SP。對我來說，如果SP保持業務邏輯，他們就會知道他們應該做什麼。我認爲SP的主要任務是用於檢索數據和/或存儲數據。如果業務邏輯已經應用到代碼中的命令鏈中，那麼只有在滿足業務邏輯時纔會調用SP。

我懷疑Adam Machanic或大多數人會主張很難理解和維護的長SP是好事。

Answer 2

存儲過程與常規函數沒有區別。無論如何，它們應該是可管理的大小。我偏向於保留存儲過程的業務邏輯，但合理的人可能會不同意。

Answer 3

我認爲現在的存儲過程不應該在整個系統上用作數據庫的唯一訪問方法。這是一個過時的架構，從長遠來看，它會帶來更多的維護問題而不是好處。 現在有更好的方法來處理每個數據訪問需求。 存儲過程的最佳用途是在某些罕見的情況下，當您希望單個定義明確且唯一的函數檢索數據時，您知道它將以相同方式被更多應用程序使用。在這種情況下，存儲過程將允許您進行DRY。 同樣在某些情況下，您的處理安全性的數據庫管理員需要以允許僅訪問SP的細粒度方式保護數據的某些部分（例如信用卡表），這是一個不錯的選擇。

除了這些情況，儘可能避免存儲過程，並堅持只使用具有繼承的所有好處的代碼，編譯器檢查，重構的工具，查詢中的枚舉而不是魔術字符串，源代碼管理，更容易部署等等等。儘可能避免SP的好處目前太長了。

但是，如果由於某種原因您決定使用存儲過程，那麼您可能會將業務邏輯放在那裏，因爲擁有如此接近數據的層，甚至不允許它包含業務邏輯，這會讓您的項目更加複雜，不會收穫使用SP的極少數優點。