一千萬個為什麽

搜索

使用ORM與存儲過程相矛盾?

我繼承了一個嚴格使用存儲過程來完成工作的Web應用程序。我喜歡使前端開發人員無法打破數據庫的方法,但我已經厭倦了用純SQL編寫對SP的調用,並希望有更好的東西。雖然我一直在尋找一個像樣的ORM(在這種情況下是Perl,但這與問題無關),但我意識到ORM可能與SP有直接的矛盾。

我的想法是,就像名稱已經告訴我們的那樣,SPs就像程序性的Pascal編程風格的代表一樣,事實上,一個Web應用程序看起來與SQL Server服務器端的Pascal很像 - 許多函數,沒有真正的命名空間。相比之下,我們試圖完成大部分編程OOP風格(或功能性,這是另一個話題),所以實際上過程式SP並不適合幹凈的對象層次結構。同時,關系邏輯可以幹凈地(通過ORM)轉換為對象,但不是程序,這可能是為什麽大多數ORM不能很好地支持SP(但我不是該領域的專家)。從某種意義上說,SP ORM。

所以這兩個問題是:

  1. 我是否認為運行ORM時使用普通表格更好?
  2. 市場上是否有任何“面向對象的存儲過程”,從關系模型構建?顯然,有面向對象的數據庫,但我對“服務器端的ORM”感興趣。

最佳答案

“我是否正確地認為運行ORM時使用普通表格會更好?”

是。

RDBMS應該專註於持久存儲,僅此而已。

如果你這樣做,你會發現你可以 - 輕松地 - 用你的OO語言構建一個訪問層。所有的“前端”開發人員都必須使用訪問層,並且不能破壞數據庫。

“面向對象的存儲過程?”

Oracle具有PL/SQL的類OO功能。

不要浪費任何時間。重點關註持久性(在RDBMS中)和應用程序處理(不在RDBMS中)之間的幹凈分隔。

許多人會向你發送討厭的郵件,說“這個供應商把所有這些功能都放在那裏,這意味著你應該使用它們”以及“存儲過程出了什麽問題?”和“一個好的DBA比一個充滿前端開發者的房間好”等等。

我不知道為什麽人們聲稱存儲過程是“更好”的,但是很多系統最終都到達了存儲過程和觸發器變得如此繁重以至於不得不被重寫的隔離墻。

我從來沒有見過任何人抱怨說他們在數據庫之外有太多的應用軟件。

繼續在這裏遵循你的想法 - 使用ORM - 避免存儲過程。

轉載註明原文: 使用ORM與存儲過程相矛盾?