Question

我已经制定了公司政策，所有数据访问都必须通过Sprocs完成。这包括选择，更新，删除和插入。我们开始被他们淹没了。我是否过度杀戮？正在执行选择，结果转储到自定义DAL中。

我觉得这是一个神圣的战争问题。我倾向于认为sprocs对于简单的选择来说是过度杀伤，但是更新，插入和删除的必要性。 sprocs的一个论点是安全性。某些用户不应该访问应用程序的某些部分。谁在这里实际上在网站的数据库上创建了多个用户？没有手？

我还需要检索有关多个表的统计信息。这是一个对UDF进行大量调用的查询。这些统计数据会按分钟变化。我应该使用视图还是sproc？我正在学习一个sproc，因为无论如何，视图只需要重建自己。这是正确的假设吗？

Answer 1

好吧，这会让我听起来像是一个混蛋，但我真的不是故意的。我对你问题的回答是另一个问题。

“你有什么业务定义发展政策，如果你不这样做了解数据库的工作原理？“

你说“视图每次都必须重建自己”。您是否说每次查询时都会重新编译带有视图的代码？因为这绝对不是真的，（至少在Oracle和SQL Server上）。使用视图是一种比存储过程更灵活的获取高效查询的方法，因为优化程序可以根据您的使用方式重新优化视图。一旦完成，查询计划就会被缓存，因此不必重新编译。例证：您创建此视图：

CREATE VIEW myOrders AS
SELECT c.CustomerID, c.LastName, c.FirstName, o.OrderID, o.OrderPrice
FROM Customers c
LEFT JOIN Orders o
   ON o.CustomerID = o.CustomerID;

然后，您决定要列出名为John Smith的所有客户的列表：

SELECT c.CustomerID
FROM myOrders
WHERE c.LastName = 'Smith' AND c.FirstName = 'John';

因为它是一个视图，所以“Orders”的连接会被优化掉。你是否试图在存储过程中对其进行模块化，好吧，你做不到。你可能不得不为此目的制作另一个sproc。很快你就会遇到问题，这是一个几乎无法维护的过程。

为什么使用存储过程？你试图解决的问题是什么？封装？我认为对于SELECT，UDF可能更有用。我还认为中间层的LINQ类型查询更加灵活。您是否尝试使用存储过程来优化性能？如果是这样，请了解并了解您运行的每个即席查询都会得到优化和缓存。如果您正在使用SQL Server 2005+，您甚至可以强制它参数化和缓存您的查询计划，即使您没有明确指定参数。

存储过程有其自己的位置，但它们的可维护性，使用灵活性以及是甚至性能的缺点意味着您应该明智地使用它们，而不是为您的开发人员创建一揽子策略。

Answer 2

除存储过程外，您还可以允许访问视图。您仍然可以控制对视图的访问，但是一个视图可以替换许多存储过程。

您还可以按功能对存储过程进行分组，并为每个组使用前缀。比如，cart_AddItem或user_GetPreferences。这是一项追溯实施的大量工作，但启动永远不会太晚。

如果您正在维护一个由多个程序和/或网站访问的数据库，那么存储过程是我所知道的唯一可以保持复杂性可管理的方法。另一方面，如果它只是一个网站，LINQ之类的数据访问层可以很好地工作。

SQL视图和Sprocs

2 个答案: