數據庫訪問的性能問題與瓶頸問題(2)

　　從另外的角度考慮，其實在項目初期，DBA就應該參與進來，進行數據庫的設計了，而一旦數據庫設計好了，設計得并不規范，存儲過程也些了成千上萬了，將來一旦出現性能問題，相信也夠DBA喝一壺的。

　　4.不愿意被微軟綁架。這個觀點倒是讓我感覺到意外，至少我們很多都在用微軟的.NET Framework,我們使用微軟的SQL Server數據庫，如果說我們被綁架，可能現在就已經被綁架了，SQLServer的存儲過程跟Oracle、Mysql的存儲過程是不一樣的，如果將來進行數據庫的遷移，那么可想而知后果是怎樣的。到底怎樣才是真正的被綁架?

　　5..Net與Java孰好孰壞?

　　關于這個問題的討論，一直就是個無休止的討論。scottgu把這個比作是“帶有宗教性質的技術爭論”。誠然，討論這樣的問題的確令人討厭，而且是浪費時間，而且討論的雙方都深切的關注著。討論來討論去最終也不會有結果。

　　在目前所運行的軟件系統中，我們可以看到其背后的平臺、語言等是各種各樣，MySpace是基于.NET平臺的，淘寶網是基于Java的，而Google則推崇使用Python，許多大型的電力系統還依然運行在C++平臺上，最關鍵的一點，.NET并不是沒有在大型項目中應用。只不過是Java起步早，.NET起步晚而已，要在前幾年，Java做的大型項目的確是比.NET的大型項目要多。

　　很多時候，即使是使用相同的開發語言，不同的程序員開發的程序效率就差30倍以上，甚至幾千倍以上，這點好不夸張。誠然，每門技術自有其缺點，但它們也都自有其優點，如果它的優點恰好能符合你的需要，用它就好了。重要的是，你有沒有使用好它的能力。

　　總結

　　其實總結就不必了，說點題外話吧。存儲過程在單條執行操作的時候，的確要比使用ORM要快，可是如果是執行批量的操作，使用存儲過程就會非常的費勁。之前我是這樣做的。假定更新1000條數據，數據庫里只有2個字段，循環調用1000次存儲過程需要2分鐘左右，當時我把要更新的id以參數的形式逗號分隔傳入存儲過程，在存儲過程中循環執行1000條數據，發現時間跟循環調用1000次存儲過程的時間是差不太多的，最終進行了改進，改進的方法嘛，還是把要更新的Id以參數形式逗號分隔傳入存儲過程，然后使用update table set value=’value’ where id in select id in 分隔函數(id1,id2,id3…..)，經過這種方式，更新1000條數據的時間從2分鐘變成了200毫秒，可是問題依然不完美，方法存在局限性。

　　首先，使用這種方法參數的長度是有限制的，varchar類型最大不超過8000,nvarchar類型最大長度不超過4000.

　　其次，如果表中有多個列，要更新的也是多列，存儲過程的局限性就出來了。

　　再次聲明：文中觀點僅代表個人觀點，如果您有不同意見，歡迎共同討論。

　　最后，給大家分享個幽默視頻，來緩解下這種緊張而激烈的爭論吧。

原文轉自：http://www.anti-gravitydesign.com