数据库权限和ORMs

Question

我最近经常使用.NET的实体框架，绝对不想回到使用存储过程。然而，令人震惊的是，我正在为这个项目构建的公司制定了一项政策，其中应用程序只被授予只有访问存储过程的权限的帐户。

显然，他们认为允许应用程序直接访问表/视图会带来安全风险。我不明白这个。

1. 我的第一个问题是，有人能告诉我可以直接访问数据库的安全风险应用程序的类型吗？
2. ，如果是这样的话，还有其他的ORM解决方案可以解决这个问题(我想不出任何逻辑上的可能性)可以让我绕过分配给我的用户帐户的限制吗？还是我的理解是，我需要对表和视图的直接权限？

Answer 1

考虑一下，在特定的上下文中，限制对存储过程的访问是很有意义的。这些过程公开一个API并处理处理(例如，检查复杂的约束)，这在理论上很好。没有一种简单的方法来声明跨列约束，例如“如果A列为null，B列应该是{X，Y，Z}之一”。多个应用程序可能正在使用过程API，所有应用程序都可以从这些过程中受益，确保数据得到正确的处理。

然而，任何试图在数据库中编写大量逻辑和使用通用OOP语言编写大量逻辑的人都知道，前者往往导致不可维护的数据库锁定的非智能代码，而后者则被公认为“编写复杂应用程序/系统的方法”。

虽然存储过程API方法还远未消失，但如果看到一个新项目开始使用这种模式，我会感到非常惊讶。ORMs远非十全十美，但它们确实提供了越来越多被视为理所当然的巨大好处:整个应用程序可以用一种语言编写(Python、Java、Groovy、Ruby.)，您通常可以在几分钟内切换DBMS (例如，当您在hsqldb上运行测试时，但是在生产中使用postgresql )，从数据库到数据库的数据打包要简单得多( ORM通常返回域对象，而不是原语)，还有缓存优势等等。

有鉴于此，应用程序完全可以访问其数据库中的所有内容，这是完全可以接受的。此外，如果您有一个只允许您调用存储过程的帐户，我不建议花时间研究如何绕过访问权限:更好地利用您的时间将是争取CRUD表访问权限。

Answer 2

愚蠢的有限思维--除非他们把完整的访问逻辑放进数据库中.

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

很好地解释了为什么安全不是一个原因。正如我所说-除非完整的业务逻辑验证谁看到了数据库中的内容.这样就不再是一个多层应用程序了。