DataSet v/s數據庫

Question

在設計應用程序時，將所有業務邏輯集中在一個地方是非常好的做法。那麼爲什麼我們有時候在存儲過程中有業務邏輯呢？我們可以從數據庫中獲取所有數據並將其存儲在數據集中，然後進行處理？在這種情況下應用程序的性能會如何？

Answer 1

那麼爲什麼我們有時候在存儲過程中有商業邏輯？

因爲有時您需要在將數據返回給客戶端之前進行一些處理，那麼當您只需要一個子集時返回一堆行將是浪費的。一些複雜的東西也更容易在一個存儲過程做的，當你有涉及到臨時表或鏈接的服務器，例如

Answer 2

覺得這個簡單的例子中，它應該回答你的問題：

如果你有一個數據庫與GB的 數據橫跨一堆表和你 想要得到一個簡單的客戶 記錄和加入他們的訂單，它會是有道理的帶回客戶端 應用程序或Web服務器的GB數據只是 得到1KB實際上看起來是 ？

您希望儘量減少傳遞到應用程序層的數據量。你也想讓數據處理在最快的地方完成。將它存儲在數據集中將不會給你索引和全文搜索選項等。我們使用數據庫來存儲和檢索數據，或者我們在啓動時加載到內存中的簡單平面文件將是所需要的。如果你的應用和數據很小，那麼這可能是一種選擇，但在大多數情況下不是。

Answer 3

那麼，爲什麼我們有時在存儲過程中有 業務邏輯？

我想應該做的處理，它更有意義。

例如，如果您的應用程序有一些進程需要從應用程序&輸入較少的數據庫輸入，最好在數據庫級別完成。

這也取決於你正在嘗試做的事情&在數據庫級別支持這些事情。例如：使用正則表達式或數學函數。

我們可以獲取從數據庫中的所有數據和 其存儲在一個DataSet，然後再處理 呢？在這種情況下，應用程序的性能是 ？

我不認爲將所有數據從DB存入應用程序內存是有意義的。
答案取決於數據量是多少？它經常改變嗎？如果數據庫中的數據發生更改，應用程序的行爲如何？

一般來說，如果您有某種靜態數據，那麼在應用程序內存&中可以不這樣做。

Answer 4

那麼，爲什麼我們有時候在存儲過程中有業務邏輯呢？

另一個重要原因是安全性。您可能希望通過在存儲過程中實現代碼來監視對數據的訪問（特別是寫入訪問）。這樣，所有對數據的訪問都通過存儲過程隧道傳輸，並且可以防止可疑訪問。

Answer 5

這兩種模式都存在。

如果你需要做嚴重的數學和字符串操作或矩陣運算，你最終可能會把大量的數據庫拉到內存中。

如果你的工作有一個可以通過join和where子句解決的解決方案，那麼SQL就是適合的地方，即使人們可以提出一個哲學上的爭論，認爲它可以歸類爲商業邏輯。將基於集合的邏輯移動到中間層可能會導致在中間層重新創建關係數據庫，並且它不會很好地完成！

當行數非常少（總是會是），那麼它並不重要。與單元測試，工具支持等有關的C＃或java相比，SQL是一種相當貧窮的編程語言，因此如果數據庫中有100行（並且永遠不會有更多！），那麼通過一切手段，感覺自由把它們放入內存數據結構中 - 儘管即使在那裏，數據庫在排序等領域仍然會更有效率和更少錯誤。