簡單的例子,select sqrt(100);還是select 100;拿到數據然後在邏輯代碼中開方?


It depends.

可以從時間複雜度的角度來判斷這個問題, 如果一個問題是On, 就走資料庫, O1就走客戶端.

舉例來說, 一個頁面展示10條數據, 對於這個頁面來說, 排序是On的, 因為排序和頁面展示的數據條數無關, 需要遍歷所有數據; 但是對於頁面上貨幣的標化就是O1的(永遠只有10次運算), 這個就可以方面頁面上來做.

在實際情況, 根據API封裝的粒度和業務不同, 還是需要具體情況具體分析.


作為一名DBA,我認為資料庫只用來做簡單的操作,複雜的運算放在代碼邏輯層面,有助於資料庫的更好的


業務層計算。

資料庫應只做增刪改查的操作。任何情況下都建議這麼做。1. 資料庫做邏輯會有無窮無盡的坑。要知道你認為簡單的代碼,後面有新需求會產生各種問題。2. 性能,業務層都是內存處理,資料庫會涉及大量io

3. 方便移植。如果有需要改底層資料庫,比如mysql改postagesql,那麼sql越簡單,移植工作量更少。

4. 優化。如果代碼是性能瓶頸,在業務層,低級語言改造,分散式等等各種花樣隨便玩。資料庫的話就…
前面幾個回答都是教科書式的,但是在現實生活中往往更新/改變業務層比更改資料庫要頻繁地多。而且業務層的deployment 往往更麻煩。有一個強大伺服器上的好資料庫(Oracle) 完全可以把邏輯放在資料庫里,維護更簡單。

資料庫資源寶貴,當然應該放在業務方處理


雖然說具體情況具體分析,但一般地來說:如無特別特殊的原因,能放到業務節點處理的邏輯都應該放到業務節點處理,而不應該把計算任務交給資料庫服務節點來處理。原因其實很簡單:一般如果設計上沒有太大問題,業務節點的橫向擴展都是比較容易的,而資料庫服務一般都是一個比較「中心化」的服務,它的性能是寶貴的,而且橫向擴展難度大,維護難度也更高。


推薦閱讀:
相关文章