“真实”数据库授予用户什么权限？
在阅读@ PerformanceDBA的回答Historical/auditable database他做了这样的说法：“真实”数据库授予用户什么权限？
在真实的（标准ISO/IEC/ANSI SQL）数据库，我们不给 INSERT/UPDATE/DELETE权限的用户。我们授予SELECT和 仅供参考（对于选定用户）所有INSERT/UPDATE/DELETE都在 中编码，这意味着存储过程。然后，我们将每个 存储过程授予选定用户（使用ROLES减少管理）。
这是真的吗？如何动态地生成INSERT/UPDATE的ORM工具？
UPDATE
OK，所以这里是一个例子。我有一个Web应用程序有两个接口，一个管理员和用户。管理端使用能如果不是数以千计不同的SQL命令动态地产生数百重 ORM。
用户交互非常简单，我有十几个SP处理任何更新/插入一些投票按钮。显然，应用程序运行的用户拥有非常不同的权限集。在管理员端，ORM的数据库用户对相关表具有完全的CRUD访问权限，因此根本没有任何SP用于此应用程序 - 并且我不会想到在不通过领域模型中的业务逻辑的情况下触摸数据。即使批量数据导入也会通过ORM进行处理。在用户方面的SP我只考虑这个原则的一个小小让步，仅仅是因为它们是一种特殊情况。
现在，我发现上述原始问题中的陈述有些令人不安，因为我认为这是一个“真实”的数据库，或者至少接近它。
它喜欢你的革命狂欢狂欢。 ORM可以利用SP，但并不能从中获得最大收益。
SP只有当然是过去的生活方式，就像第十一条诫命一样，但是正如你指出的那样，ORM并不是那样的工作。我以前认为整个SP层本身就是一种预备白勺ORM，你把你的关系数据库，做了一堆连接，并返回一组数据与填充对象所需的列/属性。
现在，使用动态ORM类型的应用程序，需要在表上指定权限，如果您的DBA正在完成他们的工作，它的安全性也不会低，只需要更多的工作，并且需要进行更多的沟通允许在表上，如果你不需要DELETE，那么你的DBA需要知道不给它权限。
好的DBA知道具有表访问权限的安全数据库与具有SP唯一访问权限的数据库一样安全。说服不那么自信的DBA就更难了。
我不完全同意你的看法。 “SP Only”方法并不像您所传达的那样古老，它只是一种与ORM方式不同的方式。只允许在表上使用'SELECT'和在存储过程中使用'EXECUTE'，极大地减少了沙盒的使用。 – 2011-12-28 13:33:17
@Shark对不起 - 我不是故意过时的，我的意思是在ORM成为主流之前，这是事实上的标准，仍然应该用于非ORM应用程序。但对于ORM应用程序，仅SP的路线会降低ORM的优势。 – 2011-12-28 13:44:03
我会说，这是最好的设计，而我通常喜欢练。由于来自应用程序的临时查询可能混乱，难以调整，甚至更难以排除故障并进行跟踪，因此使用存储过程进行抽象级别是最容易的。该应用程序只能进行存储过程调用。把存储过程看作是数据库的API。
因此，如果以上是设计目的，那么应用程序用户只需要在数据库上使用SELECT和EXECUTE。这就是为什么：
create procedure MyTestProcedure
with execute as 'UserWithDMLRights'
as
-- your CRUD code
go
如果典型的应用程序用户只SELECT和EXECUTE，然后权限来执行上面的存储过程就足够了。存储过程中的INSERT/UPDATE/DELETE将在安全性为UserWithDMLRights的情况下执行，并且该数据库用户必须具有INSERT/DELETE/UPDATE权限。
至于奥姆斯，我倾向于同意你的看法。我相信L2S只是通过sp_executesql进行多次临时查询调用，所以我相信您会遇到一个与此理论有关的问题并使用上述安全措施。
您是否担心PerformanceDBA可能会因数据库和应用程序设计而发笑？这里描述的内容没有错。 – 2011-12-28 14:46:16
嗯，我试着总是***担心我使用的设计可能不是最好的实践，只是一个普遍的心态。 – Paul 2011-12-28 14:52:24
而且，正确的做法是，最佳做法和某人对“真实”（无论在引文中的含义）的看法不仅取决于一件事情，而且您需要了解整个应用程序，而不仅仅是数据库为您的应用找到最佳做法。如果您的应用程序使用ORM，那么仅通过ORM的SP不会允许您在ORM中应用最佳实践（延迟加载等）。 – 2011-12-28 15:15:01