針對存儲過程的情況？

任何想法/有超過3000的存儲過程的數據庫上的評論查詢/訪問超過1,400表（過於歸一化）。真的想要使用像Entity Framework這樣的技術，最好是4.0，並從這些存儲過程中獲得業務邏輯？針對存儲過程的情況？

，如果你決定要分享欣賞任何現實生活中的實際經驗&反饋。這是我繼承的一個數據庫，並且真的覺得現在是時候爲了更好的業務層而放棄存儲過程了。

2010-06-22 baskint

它工作嗎？你能保持它嗎？有問題嗎？有具體的擔憂嗎？沒有特定的「問題」，就沒有什麼可談的了。 – 2010-06-22 02:46:22

嗯，是和不是。每次通話都是一個短片。團隊在印度，我們正在使用Team City來部署前端和後端（至少現在是分開的）。這是數據訪問層中的.NET 1.1和.NET 2.0應用程序。數據表，數據行，ADO.NET，企業庫等。真的很想將這些引入.NET 3.5世界，以供初學者使用。謝謝你的答覆，斯科特。 – baskint 2010-06-22 02:53:04

哦，偶爾代碼庫會與存檔的不同步，併成爲一個麻煩。 DBIntegrations測試無法捕獲這些測試。 – baskint 2010-06-22 02:54:11

不是一個真正的回答你的問題，但你仍然可以使用存儲過程的實體框架：see here，基本上存儲過程地圖的方法調用你的上下文對象。

我的個人體驗實際上與您的相反：我通常試圖遠離EF，因爲它具有與您的應用程序緊密結合的趨勢。關於sprocs的好處是它們允許一定程度的分離（例如，我可以在不修改客戶端代碼的情況下更新數據庫）。但這當然只是我個人的看法。

來源

2010-06-22 05:24:18

是的，他們確實允許解耦，但這些sproc中的業務邏輯的數量是真的關注。它們也不是簡單的CRUD操作，而是通過幾個WHERE過濾器將十多個或更多表上的許多LEFT OUTER JOIN類型操作複雜化。然而我也看到你的觀點，我會開始你的聯繫。謝謝。 – baskint 2010-06-22 16:27:46

這取決於你所工作的商店。我在許多商店工作過，這些商店對是否利用sprocs或應用程序層的代碼存在強烈的意見衝突。問題是：你是否擁有更多熟悉維護plsql/tsql的人？

我個人很討厭存儲過程，並贊成ORM工具等，現在天，我寧願保持應用程序代碼的清潔。這只是在數據庫中變得非常舒適之後。讓數據庫代碼存在於它的本地環境中，並提供所有可用的工具。

來源

2010-06-22 02:50:11 Jubal

好點。數據庫必須從早期的Access數據庫發展而來，我想從90年代後期開始，我不確定。它使用'Y'或'N'字符來存儲布爾（ugh！）過度標準化。我聽說專家DBA和開發人員說每個sproc不會再有30個連接。我的下巴正在下降。我正試圖讓隊友們有更多的感觸，但我想用一些實際的經驗。因此，這個問題。 ;） – baskint 2010-06-22 02:59:01

聽起來像是將這些東西帶入實體框架人員的主要工作。 :-)本身並不容易出錯。儘管我感到你的痛苦！祝你好運先生！ – Jubal 2010-06-22 03:24:08

Why use Stored Procedures?

在實踐中，你會最終重構從EF遠在短短几年內，而您的存儲特效仍然可以坐在那裏準備在最新最好的客戶層使用。客戶端無關，封裝等

來源

2010-06-22 05:15:36 gbn

這是一個有效的觀點，但業務邏輯封裝的數量，未經測試的業務邏輯實際上不能很好地對業務規則/邏輯進行「單元測試」。我寧願讓他們用C＃編寫，並通過一些數據庫集成測試來執行他們的執行。但這是我的看法。同意，sproc的確經受了時間的考驗，但隨着雲計算即將到來，也許是時候離開了。 – baskint 2010-06-22 16:24:51

我沒有提到業務邏輯應該打包到proc中，但他們將擅長事務處理，數據完整性，避免多次調用等。 – gbn 2010-06-22 16:26:47

針對存儲過程的情況？

回答

相關問題