SQL 2005的框架\設計和實現的一般建議

Question

我正在翻新一個現有的ASP.Net Web應用程序，它有一個全功能的SQL 2005數據庫作爲其後端。通過功能完備的功能，我的意思是有很多事情（實際上幾乎所有的CRUD操作）都是使用SP從數據庫中處理的。

所以，我的第一個問題是，基於像性能，可伸縮性和安全性這樣的參數，SP良好的廣泛用法？我也比較像的LINQ to SQL最新的東西問這個，動態查詢生成框架，比如NHibernate的，等等。

的DB會在每個表處理幾百萬 記錄，我們」已經一個 廣泛查找/聯過程（我 計劃使用的看法吧）所以， 關注的是，是否值得繼續在 SP的「CRUD」執行 - 顯然，這也制約了一些 驗證和業務約束 進入SP層（我試圖 儘量減少它），但仍然如果它的價值 這三個主要參數 - 性能，可擴展性和安全性 權衡是可以承受的。

---

而一些俏皮話那些專家DBA和編程大師：

1. 是示物理緩存@服務器上的任何地方嗎？或者它們與典型的JOIN操作相同 （簡而言之，我繼續在表之間使用JOIN或創建這些JOIN的VIEW）

2. 通過EXEC的T-SQL與SP中的編譯SQL相比是否值得？ 我的意思是顯然他們提供了很大的靈活性，但是'編譯SQL'的整個好處被破壞了？ 它確實降低了複雜度，但它是否會影響性能\安全性（即SQL注入等）？框架級：將CRUD操作保留在SP中或者做一些框架，通過將它們拖動到應用程序中（如LINQ到SQL，nHibernate等）來承諾更好的折衷。我再次相信這一點是也與＃2相關。

3. 考慮到我提供的所有解釋，哪個框架適合我的web-apps？後端是SQL Server 2005+。

歡迎任何額外的創意。感謝您分享你的知識。

Answer 1

關於存儲過程對臨時查詢的「好處」 - 互聯網上有很多文章。好的例子是here和here。

查詢/ SP的性能完全依賴於SQL服務器中的執行計劃。執行計劃基於SQL Server統計信息在第一次調用期間生成，並針對這兩種SP和即席查詢進行緩存。所以，總而言之，我會說使用SP沒有合理的好處。

SP的最大缺點之一是可維護性。使用SP時，您不得不將至少部分業務邏輯移至數據庫層。 SQL不是結構化語言，在那裏維護複雜的業務邏輯是可怕的。

因此，我是「無SP」方法的「追隨者」。軟件開發不應該以數據庫爲中心，而應以代碼爲中心。通過良好的ORM框架，您可以創建真正可維護且正交的業務層組件。