數據庫查詢應該在哪裏存在？

查詢是否應該存在於需要數據的類中？查詢應該存在於數據庫中的存儲過程中，以便它們可重用？數據庫查詢應該在哪裏存在？

在第一種情況下，更改查詢不會影響其他人（其他代碼或生成報告的人員等）。在第二種情況下，查詢可以被許多人重複使用，只存在於一個地方，但如果有人打破了這些查詢，那麼他們就會被打破。

2009-10-01 Buns of Aluminum

我曾經在存儲過程解決方案方面做得很大，但是由於數據庫變得更快而ORM已經進入主流，所以在去年改變了我的調。存儲過程當然有一個地方。但是當涉及到簡單的CRUD sql時：一個插入/更新/選擇/刪除，使用ORM來處理這是我認爲最優雅的解決方案，但我相信很多人會反其道而行。 ORM將把SQL和數據庫連接建立在代碼之外，並使持久性邏輯更加流暢地與應用程序集成。

來源

2009-10-01 23:08:05

+1。 ORM的改進使存儲過程對性能的爭論變得不那麼重要。拋開性能問題，我喜歡將代碼定位在最能讓您更新和維護未來的方式中。 – jro 2009-10-01 23:11:25

這對於CRUD很不錯，但更多涉及訪問多個表的查詢又如何呢？如何訪問沒有主鍵的表（並且因爲它們屬於第三方供應商而陷入困境）？ – 2009-10-01 23:26:59

你是正確的主。 ORM不能用於每種場景。在你描述的情況下，存儲特效可能是更好的路線。我知道，領先的ORMs確實提供了對存儲過程的支持，但是沒有太多經驗可以通過orm來處理它們。 – 2009-10-01 23:31:13

我建議將它們作爲存儲過程放在數據庫中。您不僅可以獲得重用優勢，還可以確保相同的查詢（作爲選擇，更新，插入等），因爲您使用的存儲過程相同。如果你需要改變它，你只能在一個地方改變它。此外，您將利用數據庫服務器的處理能力而不是應用程序所在的服務器/計算機。這是我的建議。

祝你好運！

來源

2009-10-01 23:02:23

如果您只需要簡單的CRUD，請和Matt一起討論使用ORM。但是，如果您確實需要使用存儲過程，請將它們留在數據庫服務器中，即它們所屬的位置。 – 2009-10-01 23:20:02

這取決於它的情況。對於這兩種選擇都有非常強烈的爭論和反對意見。就個人而言，我真的不喜歡看到業務邏輯在數據庫（在存儲過程中）和代碼中分離，所以我通常希望儘可能在代碼中進行所有查詢。

在微軟的世界裏，有些東西像Reporting Services可以從類/對象中檢索數據，而不是數據庫/存儲過程（除了數據庫/存儲過程）。此外，還有像Linq這樣的代碼給你更強大的類型查詢。還有像NHibernate這樣的強大，成熟的ORM，可以用來編寫幾乎所有類型的代碼查詢。

也就是說，有些時候您正在使用查詢的「行集」類型的事物在存儲過程中比在代碼中工作得更好。

在大多數情況下，兩個選項都可以正常工作。

來源

2009-10-02 08:45:37

從我的角度來看，我認爲存儲過程是最好的選擇。首先，它們更容易維護，只需要運行腳本而不是重新編譯應用程序即可快速更改。其次，它們對安全性要好得多。您可以在sp級別設置權限，而不是直接在表和視圖上設置權限。這有助於防止欺詐，因爲用戶不能直接對存儲過程中未指定的數據庫執行任何操作。他們更容易表現調整。當您使用存儲的特效時，可以使用數據庫依賴關係元數據來幫助確定數據庫更改對代碼庫的影響。在許多系統中，並不是所有的數據訪問或甚至是CRUD操作都會通過應用程序進行，因爲在我看來，代碼會適得其反。如果所有的數據訪問都在一個地方（我支持的想法），它應該在數據庫中，所有可能需要使用它的應用程序或進程都可以訪問它。

我發現應用程序員通常不會考慮數據庫處理信息的最佳方式，因爲他們專注於應用程序而不是後端。通過將數據庫的代碼放入數據庫所在的位置，數據庫專家可以更好地查看和審查數據庫，這些專家會考慮數據庫及其性能。我們在此支持數百個數據庫和應用程序。我可以查看任何數據庫，並查找當某些內容很慢時我需要查找的代碼。我不必上傳數百個不同應用程序中的每一個應用程序代碼，只是爲了查看我需要做的工作。

來源

2009-10-02 13:18:03 HLGEM

數據庫查詢應該在哪裏存在？

回答

相關問題