什麼是更好的：sql字符串或存儲過程？

Question

我有一個使用企業庫的數據訪問層。

現在我想知道哪個更好：使用存儲過程來創建我的SQL，還是在數據訪問類中編寫SQL字符串？

Answer 1

舊文章的位，但值得一讀。

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5766837.html

Answer 2

這要看！

SP的安全性更高，執行時間更快。 字符串具有快速開發和快速更改能力的好處。

要回答你的問題，兩者都不是'更好'。

Answer 3

我總是會嘗試使用存儲過程，函數，視圖等，而不是保持SQL我的數據訪問類裏面。

如果在SQL中有一個小錯誤，我發現在SQL Server上更改Stored Proc比改變類更容易，並且必須重建和部署它。

此外還有緩存和SQL Server安全性的附加好處。

Answer 4

如果您正在開發使用C＃，這些不是唯一的兩個選項。

您還應該查看實體框架和NHibernate，看看它們提供了什麼 - 因爲它們在存儲過程和SQL字符串上都有一些優勢。

無論選擇哪條路線，最重要的是保持它的全部分離。創建表示數據的對象並使用存儲庫與數據庫進行任何交互，包括將數據轉換爲對象以傳遞迴應用程序。這意味着如果您改變了對SQL字符串，存儲過程或ORM框架的想法 - 您不必影響整個應用程序 - 只需要替換存儲庫即可。

Repoisitory模式：http://martinfowler.com/eaaCatalog/repository.html

Entiry框架：http://msdn.microsoft.com/en-us/library/aa697427%28VS.80%29.aspx

NHibernate的：http://community.jboss.org/wiki/NHibernateforNET

Answer 5

有幾個方面的答案：性能，它是如何應對變化，以及多快的速度新人們搞清楚什麼是不破壞解決方案，開發時間，測試......

至於性能，存儲過程有一個因爲它們是預編譯的並且它們的執行計劃被存儲，所以執行時間很短。 Sql文本在每次即將執行時都會被編譯（但是，大多數dbms正在爲每個查詢文本存儲計劃，所以這種影響並不那麼劇烈）。

您能夠如何保持該解決方案？我曾參與過一些相對較小的項目（< 40個表格），這些項目有數十億個存儲過程 - 因爲您無法知道其他影響其他因素，所以修改任何內容真是太麻煩了。

對於某些映射器（比如實體框架或類似的），你將不得不首先學習這個工具，但它確實值得回報 - 不寫入sql，並且如果你的dbmodel改變了映射器可以自動更新它的實體，所以沒有「無效的列名「或類似的錯誤。

底線是 - 如果你有時間實施一些ORM。如果你不那麼只是使用普通的SQL。僅在性能關鍵操作中使用存儲過程。

希望它有幫助。

致以問候

Answer 6

取決於您想要達到的目標以及涉及的數據量。

根據我個人的經驗，如果您有大量數據，並且您希望快速處理使用SP，因爲每次撥打電話時都不會重新編譯每條SQL語句。如果你只有少量的數據，那麼實現一堆SP是沒有意義的。

如果您沒有太多需要「一次處理數據庫」的數據，那麼您可能會考慮使用某種ORM或純SQL語句，因爲它們可能會更適合您的架構。

Answer 7

當您使用SQL語句時，使用parameterized queries獲得的性能和安全性也很有價值。

安全性提高顯而易見，但性能也有所提高。 DBMS（在SQL Server的情況下）會散列查詢的文本（但不包括其參數）以查看它是否已經有執行計劃。

如果您的查詢是參數化的，則第一次執行會導致編譯，但對於第二次執行和後續執行，執行計劃將被緩存，因爲查詢文本完全相同。另一方面，如果您的查詢是純SQL，則每個執行都可能產生一個編譯，因爲每個查詢都稍有不同。

Answer 8

＃1會更好，如果有對

I need an enterprise class, big boy answer. 

那麼多的人誰提供答案，證明他們不是在銀行或公共事業或投資或大型零售商或製造工作的複選框。例如，所有這些答案都以每個數據庫一個應用程序的簡單世界爲生。第二個增加一些複雜性，這些解決方案顯示他們的疣。如果您的公司需要第二個應用程序來使用該數據庫，則必須強制其他開發團隊使用您的DAL或您的ORM。如果他們使用的技術不支持您的DAL或您的ORM，該怎麼辦？此外，如果你在這裏提出這個問題，你可能沒有權力在其他團隊中強制執行標準。

但

如果其他應用/技術來你的數據庫，然後他們就可以訪問你的數據庫。如果您的CRUD和數據邏輯處於存儲過程中，那麼每個應用程序都將使用相同的邏輯，全部集中在一個地方。

有幾個人說在代碼而不是數據庫中進行更改會更快。再一次，這是對SDLC的非常簡單的看法，似乎主要關注於開發而不是維護。它離開你的盒子後，可以部署在上千臺桌面上。或者40個應用服務器。但在絕大多數情況下，只有一個數據庫。（是的，在大男孩的世界中，我們也有分佈式數據庫，但應用程序幾乎不在一個地方，大多數數據庫都是）。

一位回答者表示，如果您瞭解ORM，則永遠不需要學習SQL。 SQL是一項非常有價值的技能，它不僅值得學習，而且是每個業務開發人員的生命線。即使使用NoSQL數據庫的公司也使用SQL數據庫，我敢打賭，Facebook和Digg擁有AR/AP/GL的RDBMS。

更不用說SQL注入。永遠不要動態構建和執行SQL，以避免最好的方法。這最好用存儲過程來完成，參數的大小和類型應適當，並在SQL中作爲綁定變量執行，而不是連接在一起。