將我的web應用程序的常見SQL查詢存儲在數據庫中以供執行使用時，是否認爲是瘋狂的？或者這是常見的做法？或者是不可能的？存儲的查詢？
我的想法是這樣，我避免了將SQL編碼到我的應用程序文件中，並添加了另一個抽象層次。
這是瘋了嗎？這是一個存儲過程是什麼？或者那是別的？
編輯：下面的答案爲「存儲過程」背景是有用的，但沒有回答我的核心問題：一個是「存儲過程」只是當我有一個包含查詢能夠在數據庫表叫做？即像這樣的東西
INDEX | NAME | QUERY
1 | show_names | "SELECT names.first, names.last FROM names;"
2 | show_5_cities | "SELECT cities.city FROM cities LIMIT 0,5;"
etc.
或者是否有更復雜的機制，包含存儲過程的概念？我的例子是人們做某事的一個實際例子嗎？
隨着爲什麼使用存儲過程MUG4N最偉大的原因，這裏有三個：
安全
您可以授予訪問您的應用程序，同時拒絕直接訪問表來執行存儲過程。
認爲縱深防禦。如果您的應用程序被破解，那麼它們將被限制爲只執行您定義的程序。這意味着像'drop table'這樣的東西會被明確禁止，除非你有一個程序來做到這一點。
相反，如果你的應用程序被破解，你允許應用完全訪問您的SQL Server，那麼兩件事情之一會發生。要麼你的數據消失和/或黑客很容易得到一份副本。
單元測試。 如果您可以直接點擊它們而無需通過應用程序本身，那麼單元測試您的查詢就容易多了。
在航班變更： 如果您需要在您發佈您的網站，修改查詢，它更容易只是做出比重新部署可能已經經歷了自上次部署其他更改代碼PROC變化。例如，假設您的頁面效果不佳。評估之後，您確定只更改查詢中的連接就可以解決此問題。修改proc並去。
THX的另外 – MUG4N 2010-05-06 10:50:01
給你綠色的檢查，爲您的文章和您的評論（這回答了具體的問題） 。 – phpeffedup 2010-05-06 18:47:19
在我看來，你應該明確地使用存儲過程。這是常見的做法！
這裏提供了兩個使用存儲過程的優點：
他們將在各種環境中運行，沒有必要重新創建的邏輯。由於它們位於數據庫服務器上，因此使用的應用程序環境沒有區別 - 存儲過程保持一致。如果您的設置涉及不同的客戶端，則使用不同的編程語言 - 邏輯保留在一個地方。 Web開發人員通常較少使用此功能，因爲Web服務器和數據庫服務器通常緊密相連。但是，在複雜的客戶端 - 服務器設置中，這是一個很大的優勢。客戶端在更新後會自動與過程邏輯同步。
它們可以減少網絡流量。複雜的重複性任務可能需要獲得結果，向它們應用一些邏輯，並使用它來獲得更多結果。如果這隻需在數據庫服務器上完成，則不需要將結果集和新查詢從應用程序服務器來回發送到數據庫服務器。網絡流量是導致性能問題的常見瓶頸，存儲過程可以幫助減少這種情況。但更多的時候，數據庫服務器本身就是瓶頸，所以這可能不是什麼好處。
「Web開發人員通常較少使用此功能，因爲Web服務器和數據庫服務器通常緊密相連，但在複雜的客戶端 - 服務器設置中，這是一大優勢。」同意..這可能不是一些應用程序的情況。但是在大多數Web開發平臺上，我認爲這通常是可以避免的。 – 2010-05-05 21:03:09
對於用戶數量有限且數據要求相當簡單的相對簡單的網絡應用程序，存儲的特效可能比他們的價值更麻煩。但是，在複雜的企業環境中，它們可以在可伸縮性和性能方面發揮巨大作用。 – camainc 2010-05-05 21:06:51
它們可能會對性能產生負面影響，特別是使用緩存的計劃和直方圖優化指標 - 並且那更不用說收口窺視的問題導致計劃中毒 - 但IIRC MySQL不與調試航線實現綁定，偷看 – symcbean 2010-05-06 12:21:55
的想法肯定有它的吸引力 - 但問題是，他們幾乎是不可能的規模。我從來沒有見過一個可擴展的解決方案，以保持存儲的特效（尤其是在MySQL），這並沒有使我快門。
因爲它似乎你的標題的PHP/MySQL的路線，我給我的經驗與存儲特效的幾個例子在MySQL：
存儲過程只是一個或多個SQL語句是「預編譯「並存在於數據庫中。您可以調用它們來返回一行或多行數據，或者更新，插入或刪除數據。
如果您告訴我們您所使用的web框架和數據庫，我們可以給你如何調用存儲過程，或者至少指向你的兩篇文章，讓你去實際的例子。
你也可以考慮使用ORM框架，比如Hibernate。這將使您擺脫完全處理SQL代碼。我是一名.Net開發人員，所以我不確定PHP/MySQL平臺上有什麼可用的，但我確定有很多選擇。
你應該想想，開發商業級分層應用程序時，總有數據庫背後的人使其安全可靠的，其他人都在應用程序邏輯和其他人後面的網頁代碼後面，這樣你就可以得到最重要的是共同努力。
一旦應用程序設計好了，每個人都開始製作他們的實現，db人員給其他人一些API來隱藏SQL，開發人員不必考慮它並專注於他們的代碼，我曾作爲db開發人員使用過一些COM技術來克服應用程序邏輯的擴展和修改或重用，這些產品中的數據庫太重要了，以至於無法將其置於非常廣泛的環境中，因此這是一個非常嚴重的問題。
但在大多數情況下，Web應用程序是通過網頁開發者所做的，他們往往沒有設計時間，所以他們不使用存儲過程使得在不久的時間大的變化，此外，他們甚至沒有安全執行或嘗試將安全性留給應用程序，使數據庫不受保護並容易受到攻擊。
如果你正在做所有事情，經常更換產品，你應該避免它們，因爲它會雙重工作，並且大部分時間都是無用的，一旦你穩定了邏輯，那麼你可以開始將更重的查詢遷移到存儲程序。
我見過一些開發人員正在做什麼更新顯示。它工作得不好，過於複雜，而且使生活困難。所以，不，這是不正常的，這不是一個存儲過程。 – NotMe 2010-05-06 15:50:36