數據庫權限和ORMs

最近我一直在使用.NET的實體框架，絕對不想回到使用存儲過程。我很震驚，雖然我正在建立這個項目的公司有一個政策，應用程序只給予帳戶，只有權限訪問存儲過程！數據庫權限和ORMs

顯然，他們認爲在允許應用程序直接訪問表/視圖時存在安全風險。我不明白這一點。

我的第一個問題是，有人能告訴我哪種安全風險應用程序可以直接訪問數據庫嗎？ AND
如果是這樣的話，有沒有其他ORM解決方案可以提供解決方法（我想不出任何邏輯可能性atm），這將允許我規避要分配給用戶帳戶的限制我？ OR是我的理解，我需要對錶和視圖的直接權限錯誤？

2010-05-12 Jonn

您是否有權更改存儲過程？存儲過程是否可以完全訪問表？ ORM對錶格的工作效果最好，但是一個好的ORM通常會退化爲以相當殘缺的方式處理存儲過程。 – 2010-05-12 11:16:42

哦。我還沒有探索過這個選擇。 – Jonn 2010-05-12 22:47:31

當你考慮這個問題時，在某個上下文中，限制對存儲過程的訪問是非常有意義的。這些過程公開了一個API並處理理論上很好的處理（例如檢查複雜約束）。沒有簡單的方法來聲明交叉列約束，如「如果列A爲空，列B應該是{X，Y，Z}之一」。多個應用程序可能會使用過程API，並且所有程序都可以從程序中受益，從而確保以正確的方式處理數據。但是，任何試圖在數據庫中編寫大量邏輯並且使用通用OOP語言編寫大量邏輯的人都知道，前者傾向於導致無法維護的，DB鎖定的不可理解代碼的高峯，而後來通常被認爲是「編寫複雜應用程序/系統的方式」。

雖然存儲過程API方法遠沒有絕跡，但我真的很驚訝地發現使用這種模式的新項目開始了。 ORM遠非完美，但它們確實提供了越來越多被認爲是理所當然的好處：整個應用程序可以用一個語言（Python，Java，Groovy，Ruby ...）編寫，您通常可以切換DBMS在幾分鐘內（例如，當你在hsqldb上運行測試時，但在生產中使用postgresql時，它可以工作奇蹟），數據庫的數據打包要簡單得多（ORM通常返回域對象，而不是原語），有緩存優勢等。

有鑑於此，完全可以接受的是，應用程序對數據庫中的所有內容都具有完全的CRUD訪問權限。另外，如果你有一個只允許你調用存儲過程的賬戶，我不建議花時間研究如何規避訪問權限：更好地利用你的時間就是爭取CRUD表訪問權限。

來源

2010-05-12 07:42:06

具有跨列約束的多個應用程序是否不會受益於實施SOA而不是在後端存儲了特效？關於「我真的很驚訝地看到一個新項目開始使用這種模式」，那麼你會感到震驚並且非常失望，因爲我希望我們的團隊只使用ORM而不是傳統存儲的項目數量procs（以及IMO可疑的ApplicationBlocks.SqlHelper） – Jonn 2010-05-12 08:09:01

Cross column！=交叉表。 ;） – TomTom 2010-05-12 08:13:32

@Jonn我不確定我們是否在同一頁面上，但我可以說是的，我同意你的看法，SOA在存儲過程中是一種更好的方法。 – 2010-05-12 08:20:27

白癡侷限的思維 - 除非他們把整個訪問邏輯到daabase，

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

對安全爲何不是理由了很好的解釋。正如我所說的 - 除非完整的業務邏輯驗證誰看到數據庫中的內容......然後再不是多層應用程序。

來源

2010-05-12 06:25:19 TomTom

這就是我想到的。我想不出爲什麼我的應用程序不應該訪問表的正當理由。並沒有這樣的業務邏輯驗證誰看到了數據庫中的內容，正如你所說的那樣。 – Jonn 2010-05-12 07:55:51

然後它變得毫無意義。我們可以談論插入/更新所需的全部內容，但純SQL的靈活性難以勝任查詢。 LINQ最終允許它在編程語言中本地暴露。放棄這一點 - 沒有任何可以獲得的回報 - 是一種公然的愚蠢跡象。 – TomTom 2010-05-12 08:14:16

有點苛刻，我仍想試着瞭解這個推理背後是否有一個很好的理由，但我不能同意你的看法。我寧願不必爲每一個程序功能使用兩種不同的語言。 – Jonn 2010-05-12 08:32:28

數據庫權限和ORMs

回答

相關問題