談談一直被開發者們過於在乎的效能問題

【本文轉自部落格園 作者：十三燕 原文連結：https://www.cnblogs.com/13yan/p/3539938.html】
軟體開發者最初為了做出某種功能而努力著。

　　當有一天，開發者們掌握了開發的門道，實現功能已經家常便飯了。

　　於是人們開始考慮更多問題，效能就是一個問題。

　　通常2-4年工作經驗的開發者會很糾結這個問題，但由於基礎參差不齊，對效能的理解也大不相同。

　　那些年也許我們過於在乎效能問題了。

　　誤區一：O/RM工具影響效能

　　發現很多人喜歡拿O/RM工具討論效能，害怕引入ORM工具以後帶來損失效能的問題，

　　不過據我所知目前一些主流的ORM工具效能都半斤八兩，ORM工具之間的比較不是效能問題，而是使用習慣的問題。

　　ORM與原生ADO.NET比較，肯定會損失一定的效能，但是帶來了提高開發效率的優勢。

　　據我所知，很多同行做著的OA、ERP什麼的系統使用者數量都不多，

　　過於計較效能問題，那就是拿5%不到的特殊情況，拒絕大多數情況提高開發效率。

　　沒有人說用了ORM就一定要每個地方都用ORM到底。

　　誤區二：儲存過程可提高效能

　　採用儲存過程本身沒有什麼問題，過於頻繁地用儲存過程，除錯就會比較煩。

　　1、程式里加斷點，然後變數複製到儲存過程里加斷點除錯。

　　2、過於依賴儲存過程，資料庫裡包含業務邏輯，業務邏輯就分散在程式與資料庫，程式碼可讀性損失。

　　3、呼叫儲存過程的確讓很多SQL語句變成了一個儲存過程名和引數，減少了網路傳輸，但很多情況下不需要這點效能。

　　4、業務邏輯都寫在儲存過程裡了，用面嚮物件語言的話就當做程式導向語言用了，對開發功能複雜的專案比較不利。

　　誤區三：大資料效能問題

　　只要接觸到幾百萬或者幾千萬就認為是大資料，有些人甚至以為MSSQLSERVER資料庫碰到千萬級的就得掛了。

　　其實不然，如果每個月以百萬級的資料增長，那麼對查詢而言這些都是小資料，利用分割槽與查詢約束還是比較容易解決的。

　　而用同樣的方法，MSSQLSERVER也能處理超越千萬級的資料。

　　資料庫真正的效能問題在哪裡?

　　真正的效能問題從宏觀上講我認為是資料庫設計問題，微觀上則是SQL調優。

　　總結

　　不該以效能為理由拒絕ORM工具，也不該濫用儲存過程。

　　關注效能從設計階段開始，不可過於糾結效能問題而損失開發效率。