我們應該在數據庫中做多少工作？ 好吧我真的很困惑，到底應該在數據庫中完成多少「工作」，以及在應用程序級別需要完成多少工作？我們應該在數據庫中做多少工作？
我的意思是我說的不是很明顯這樣的東西，我們應該將字符串轉換成散列SHA2在應用程序級別而不是數據庫級別..
反倒是的東西，更模糊，包括但不限到「我們是否應該檢索4列的數據並在應用程序級別進行大寫/連接，還是應該在數據庫級別執行這些操作並將計算結果發送到應用程序級別？
如果您可以列出還有其他的例子會很棒
一般來說，它是一個很好的p ractice僅預期來自數據庫的「Data」。它取決於應用程序，應用商業/域邏輯並理解檢索的數據。其強烈建議做以下事情中的應用層：
1）格式日期 2）應用數學函數，諸如內插/外插等 3）動態排序（基於列）
然而，有時需要在數據庫級別完成一些事情。
在我看來，應用程序應該使用數據和數據庫應該提供它們，並且應該明確地分離關注點。因此，數據庫會根據請求的條件對記錄進行排序，排序和過濾，但是應用程序會將某些業務邏輯應用於該記錄，並將它們「轉換」爲對用戶有意義的內容。
例如，在我以前的公司，我們曾在大量的工作時間計算應用程序上工作。這種應用程序的一個顯而易見的功能是跟蹤員工休假天數 - 員工每年有多少天，他使用了多少人，剩下多少人，等等。基本上我們可以編寫一些觸發器和程序來自動更新這些列。因此，當員工在假期時間內批准了他申請的天數時，他會從他的「假期游泳池」中獲取並添加到「休假日」中。相當容易的東西，但我們決定在應用程序級別和男孩中明確表示，很快我們很高興我們這樣做了。申請必須符合勞動法的規定，並且很快就會發現，並非所有員工的休假日都是平等計算的，有時候休假日根本就不是休假日，除了這一點外。如果我們把這個「簡單」的操作放到數據庫中，我們必須對數據庫進行版本更新，以便對假期相關的邏輯進行一點點改變，並且這會導致我們直接在客戶支持領域陷入困境，因爲事實上可能只更新應用程序而不需要更新數據庫（當然，除了明確的「突破」時刻，其中數據庫結構發生了變化）。
這真的取決於你需要什麼。
我喜歡在數據庫中做我的業務邏輯，其他人則反對這種做法。
您可以在SQL中使用觸發器和存儲過程/函數。
鏈接爲MySQL：
http://dev.mysql.com/doc/refman/5.5/en/triggers.html
http://www.mysqltutorial.org/introduction-to-sql-stored-procedures.aspx
http://dev.mysql.com/doc/refman/5.5/en/stored-routines.html
我這樣做觸發器中的業務邏輯的理由和存儲理線
請注意，我不是在談論彎曲數據庫結構走向業務邏輯，我正在談論把業務邏輯放在觸發器中並存儲起來程序。
有些人對此非常不同意，但這種方法對我很好，並且簡化了我的應用程序的調試和維護。
根據我的經驗，我發現很多應用程序都以一組簡單的表開始，然後使用少量存儲過程來提供基本功能。這很好，它通常產生高性能並且易於理解，同時也減輕了對複雜中間層的任何需求。
但是，應用程序的增長。看到有數千個存儲過程的大型數據驅動應用程序並不罕見。將觸發器加入混合中，並且對於除原始開發人員以外的任何人（如果他們仍在處理它），您都有一個應用程序，這是非常難以維護的。
我會放話在應用哪個地方最數據庫中的邏輯 - 他們可以很好地工作，當你有一些很好的數據庫開發人員和/或你不能改變一個傳統的模式。我這樣說的原因是，當你讓他們控制模式時，ORM會從應用程序開發的這一部分中消除很多痛苦（如果不是，你經常需要做很多工作才能使它工作）。
如果我設計一個新的應用程序，然後我通常會選擇由我的應用領域決定的模式（其設計將是代碼）。我通常會讓ORM處理對象和數據庫之間的映射。當涉及到數據訪問時，我會將存儲過程視爲規則的例外（與使用ORM來有效生成複雜輸出相比，報告在sprocs中更容易）。
要記住，雖然最重要的一點，是沒有「最佳實踐」，當談到設計。開發人員可以根據您的設計權衡各個選項的優缺點。
做數據庫中的'數據庫工作';即有效地選擇和存儲數據。 –